path: root/5b/215bd77dbacf804ca25062321863d398265804

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DFC11C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 16:53:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C102A402F7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 16:53:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F4ChfL3tPbeZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 16:53:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 70C05402F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 16:53:54 +0000 (UTC)
Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com
 [209.85.167.49]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20SGrpha031826
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 28 Jan 2022 11:53:52 -0500
Received: by mail-lf1-f49.google.com with SMTP id n8so12997936lfq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 08:53:52 -0800 (PST)
X-Gm-Message-State: AOAM533HTgdqWwf0ykKkBWmv04qqphbewT0d3RkZ9ulHABCc1Fq6wVET
 E3qZKYGoGkSr7WO9hwLLHW2wDUOs41Tnp3L5RcU=
X-Google-Smtp-Source: ABdhPJys5CbqvbKDoh1GAJOsMva2fYNhXe6cM3pqFO+v5BSBEhKnD7Ya32mk7EriLfXT4VYI6pQWRQ1gKaxqbHM2ciA=
X-Received: by 2002:a05:6512:31cf:: with SMTP id
 j15mr6688560lfe.670.1643388831346; 
 Fri, 28 Jan 2022 08:53:51 -0800 (PST)
MIME-Version: 1.0
References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
 <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com>
 <CABPZDUyMmyt0UCmHYfm+s-zs=iLjxXB0VtdJZ64X5HA3XLFESA@mail.gmail.com>
In-Reply-To: <CABPZDUyMmyt0UCmHYfm+s-zs=iLjxXB0VtdJZ64X5HA3XLFESA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 28 Jan 2022 08:53:40 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhx3LmCW8Cup=mzmhosxu=WD=HVOk1pFYNe3oTmfQwJFg@mail.gmail.com>
Message-ID: <CAD5xwhhx3LmCW8Cup=mzmhosxu=WD=HVOk1pFYNe3oTmfQwJFg@mail.gmail.com>
To: Thibaut Le Guilly <thibaut@cryptogarage.co.jp>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000085341405d6a74777"
Subject: Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2022 16:53:56 -0000

--00000000000085341405d6a74777
Content-Type: text/plain; charset="UTF-8"

Thibaut,

CSFS might have independent benefits, but in this case CTV is not being
used in the Oracle part of the DLC, it's being used in the user generated
mapping of Oracle result to Transaction Outcome.

So it'd only be complimentary if you came up with something CSFS based for
the Oracles.

Best,

Jeremy


On Thu, Jan 27, 2022 at 12:59 AM Thibaut Le Guilly via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> Lloyd, thanks for this excellent writeup. I must say that indeed using CTV
> seems like it would very much lower the complexity of the DLC protocol (and
> it seems like APO would also work, thanks Jonas for pointing that out).
> Though thinking about it, I can't help wondering if the ideal op code for
> DLC wouldn't actually be CHECKSIGFROMSTACK? It feels to me that this would
> give the most natural way of doing things. If I'm not mistaken, this would
> enable simply requiring an oracle signature over the outcome, without any
> special trick, and without even needing the oracle to release a nonce in
> advance (the oracle could sign `event_outcome + event_id` to avoid
> signature reuse). I must say that I haven't studied covenant opcodes in
> detail yet so is that line of thinking correct or am I missing something?
>
> Cheers,
>
> Thibaut
>

--00000000000085341405d6a74777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Thibaut,=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000">CSFS might have independent benefits, but in this case CTV is not be=
ing used in the Oracle part of the DLC, it&#39;s being used in the user gen=
erated mapping of Oracle result to Transaction Outcome.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">So it&#39;d o=
nly be complimentary if you came up with something CSFS based for the Oracl=
es.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Jeremy</div><br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 27, 2022 at 12:59 AM Thi=
baut Le Guilly via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>Lloyd, thanks =
for this excellent=C2=A0writeup. I must say that indeed using CTV seems lik=
e it would very much lower the complexity of the DLC protocol (and it seems=
 like APO would also work, thanks Jonas for pointing that out). Though thin=
king about it, I can&#39;t help wondering if the ideal op code for DLC woul=
dn&#39;t actually be CHECKSIGFROMSTACK? It feels to me that this would give=
 the most natural way of doing things. If I&#39;m not mistaken, this would =
enable simply requiring an oracle signature over the outcome, without any s=
pecial trick, and without even needing the oracle to release a nonce in adv=
ance (the oracle could sign `event_outcome=C2=A0+ event_id` to avoid signat=
ure reuse). I must say that I haven&#39;t studied covenant=C2=A0opcodes in =
detail yet so is that line of thinking correct or am I=C2=A0missing somethi=
ng?</div><div><br></div><div>Cheers,</div><div><br></div><div>Thibaut</div>=
</div>
</blockquote></div></div>

--00000000000085341405d6a74777--