path: root/23/5873e9825b8a231ce869ecc924cd14d236b229

Return-Path: <thibaut-leguilly@garage.co.jp>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AD74BC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:51:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 9435141704
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:51:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UC_GIBBERISH_OBFU=1]
 autolearn=no 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 wJ7C2wfESXDZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:51:03 +0000 (UTC)
X-Greylist: delayed 00:05:34 by SQLgrey-1.8.0
Received: from mta02.mta.hdems.com (mta02.mta.hdems.com [52.199.63.161])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 932F441703
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:51:02 +0000 (UTC)
Received: from mo.hdems.com (unknown [10.5.20.57])
 by mta02.mta.hdems.com ('HDEMS') with ESMTPSA id 4JkhhQ3gygz2K1r8l
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:45:26 +0000 (UTC)
X-HDEMS-MO-TENANT: garage.co.jp
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com.
 [209.85.208.69]) by gwsmtp.prod.mo.hdems.com with ESMTPS id
 gwsmtpd-trans-ae28d5b4-60a5-4f96-a281-ab98b91ff06b
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jan 2022 00:45:25 +0000
Received: by mail-ed1-f69.google.com with SMTP id
 k5-20020a508ac5000000b00408dec8390aso477048edk.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 16:45:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=zS9lLelH1foE2ef/5KQV2/bkWStnX16orG1dldZwTHI=;
 b=ohxGAZFxPShP1M5C4eiGfsSzOw4nqHnXpivTM7BgIQI46m2rJu1QXD9LuFg0i3C91t
 7NidqH9YXDovLW9Liu3E4wG8ahlquNHwQkAyWggeW73Ka6M3Pryz+p+EXNJuTW6AX8Js
 AwbfwVol4zxFRP1DvF1q0r/t8a3OrDR1smm8xmG0jbpchh4Yyb7101RLQFV2rc/LiP8H
 7GCyNeiKxRmZm0zp1UaZy+oeRlIkQvKi43bTzThUXbsqcuCTp6TqdOv6XaDDO+13qJhi
 B8yO0Wtok6RMHcBpfvEbgJcsbVqlQO8iWCE8ftd2fIVwvZyy0g1NdXuqtd0q9qQjof1n
 qSSA==
X-Gm-Message-State: AOAM530pIXp/8Ms9Usn8IAWiF6kbRTNX4HJ9Y0f/fe8gjZh0zI87cG+H
 kP7pi+DobfLtScoActBYwpwJgNhhR/T0GDFRhMda5oF3y6/kuB4h7iYp/Kw4M/TMRXPSeqC1wi9
 AbEyRZwNS5DzUY893xkW+eSwSSOFFzACXBBXNEd75yQmu+pYh1Wcax++LSZ88QoJaL8HHFi8Zne
 xdhqOltfgC+wVaFlBXzLKEJYo8e7GwHKoZ4QnMjpDNee/bZ1dqDNvkVMwU2/A+nZpFXU40e+WCs
 HObkphlgN48+YmqK1A3btBz/x024Zo7QVt9FTTVeec8ui6A3SJmiGhidC84HgW4n2yMeM6PJQDq
 Sa3j5E+JHsvKvM0+Gz/LjX/nPcc=
X-Received: by 2002:a05:6402:4411:: with SMTP id
 y17mr1394757eda.175.1643244323984; 
 Wed, 26 Jan 2022 16:45:23 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyJ3B+zYITCBM1RpGHhO+6yuep2TyyFj9ensLz8fFjj3P52A+Tdsn6kS2AfNm7YDNRbK1SNX2k3UmDx4ipqNWw=
X-Received: by 2002:a05:6402:4411:: with SMTP id
 y17mr1394740eda.175.1643244323745; 
 Wed, 26 Jan 2022 16:45:23 -0800 (PST)
MIME-Version: 1.0
References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
 <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com>
In-Reply-To: <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com>
From: Thibaut Le Guilly <thibaut@cryptogarage.co.jp>
Date: Thu, 27 Jan 2022 09:45:12 +0900
Message-ID: <CABPZDUyMmyt0UCmHYfm+s-zs=iLjxXB0VtdJZ64X5HA3XLFESA@mail.gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000324bbe05d685a28d"
X-Mailman-Approved-At: Thu, 27 Jan 2022 08:59:30 +0000
Cc: dlc-dev@mailmanlists.org
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: Thu, 27 Jan 2022 00:51:07 -0000

--000000000000324bbe05d685a28d
Content-Type: text/plain; charset="UTF-8"

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

On Wed, Jan 26, 2022 at 1:27 AM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thank you, that's an interesting application of OP_CTV.
>
> Perhaps worth pointing out that this does not require OP_CTV but could
> also be
> enabled by other covenant constructions. For example, it seems like
> ANYPREVOUT-based covenants provide similar benefits. The script of the
> Taproot
> leaves could be set to
>
> <sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY
>
> where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public key
> P = G.
> When using nonce R = G, signature creation has negligible computational
> cost (s
> = 1 + H(R, P, m)). A downside compared to CTV is the additional overhead
> of 64
> witness bytes (<sig>).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi,<div><br></div><div>Lloyd, thanks for this excellent=C2=
=A0writeup. 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&=
#39;t help wondering if the ideal op code for DLC wouldn&#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 requiri=
ng an oracle signature over the outcome, without any special trick, and wit=
hout even needing the oracle to release a nonce in advance (the oracle coul=
d sign `event_outcome=C2=A0+ event_id` to avoid signature reuse). I must sa=
y that I haven&#39;t studied covenant=C2=A0opcodes in detail yet so is that=
 line of thinking correct or am I=C2=A0missing something?</div><div><br></d=
iv><div>Cheers,</div><div><br></div><div>Thibaut</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 26, 2022=
 at 1:27 AM Jonas Nick via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you, th=
at&#39;s an interesting application of OP_CTV.<br>
<br>
Perhaps worth pointing out that this does not require OP_CTV but could also=
 be<br>
enabled by other covenant constructions. For example, it seems like<br>
ANYPREVOUT-based covenants provide similar benefits. The script of the Tapr=
oot<br>
leaves could be set to<br>
<br>
&lt;sig&gt; &lt;G&gt; CHECKSIGVERIFY &lt;CET_i&gt; CHECKSIGVERIFY<br>
<br>
where &lt;sig&gt; is an ANYPREVOUTANYSCRIPT signature of the CET for public=
 key P =3D G.<br>
When using nonce R =3D G, signature creation has negligible computational c=
ost (s<br>
=3D 1 + H(R, P, m)). A downside compared to CTV is the additional overhead =
of 64<br>
witness bytes (&lt;sig&gt;).<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000324bbe05d685a28d--