From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id AD74BC000B for ; 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 ; 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 ; 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 ; 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 ; 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 ; Thu, 27 Jan 2022 00:45:25 +0000 Received: by mail-ed1-f69.google.com with SMTP id k5-20020a508ac5000000b00408dec8390aso477048edk.13 for ; 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: <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com> In-Reply-To: <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com> From: Thibaut Le Guilly Date: Thu, 27 Jan 2022 09:45:12 +0900 Message-ID: To: Jonas Nick , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > CHECKSIGVERIFY CHECKSIGVERIFY > > where 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 (). > _______________________________________________ > 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
Hi,

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'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 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't studied covenant=C2=A0opcodes in detail yet so is that= line of thinking correct or am I=C2=A0missing something?

Cheers,

Thibaut

On Wed, Jan 26, 2022= at 1:27 AM Jonas Nick via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
Thank you, th= at'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 Tapr= oot
leaves could be set to

<sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY

where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public= key P =3D G.
When using nonce R =3D G, signature creation has negligible computational c= ost (s
=3D 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/mail= man/listinfo/bitcoin-dev
--000000000000324bbe05d685a28d--