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 DFC11C000B for ; 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 ; 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 ; 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 ; 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 ; Fri, 28 Jan 2022 11:53:52 -0500 Received: by mail-lf1-f49.google.com with SMTP id n8so12997936lfq.4 for ; 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: <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com> In-Reply-To: From: Jeremy Date: Fri, 28 Jan 2022 08:53:40 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Thibaut Le Guilly , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Thibaut,=

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

So it'd o= nly be complimentary if you came up with something CSFS based for the Oracl= es.

Best,

Jeremy


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

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't help wondering if the ideal op code for DLC woul= dn'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 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't studied covenant=C2=A0opcodes in = detail yet so is that line of thinking correct or am I=C2=A0missing somethi= ng?

Cheers,

Thibaut
=
--00000000000085341405d6a74777--