path: root/41/4fb8d9b352ad86b4dc21450cb3a78f53802202

Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ED7B5C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 13:22:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CC9F940B66
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 13:22:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2ydZK-q7-UIk
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 13:22:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com
 [IPv6:2607:f8b0:4864:20::833])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6598240BAF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 13:22:34 +0000 (UTC)
Received: by mail-qt1-x833.google.com with SMTP id d14so3193312qtw.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 06:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=PIpPipEkxhvDuZjX0V8hFXSmkZraZsch/3nxDDh3bmk=;
 b=2j4Aj/N/T9aQyJtu0LUQnnuHSAqnUho2BMwwnv0s7hwxU4wdtp19blNka0ow0mufr1
 VRdXFB8MELeD3q1oJKnwlGod8HmnX0KdEM4LI9otEIGsDKlqUAcFJ86M7FEBaBwOiX3l
 gvhMEbj23yY0Ks07+9cOe5oz6A7cJ7ctqyxXtIT5vkCJw0Zg0XyIn3iG2wbPQCN62Q9P
 zffaFv8YN/ZWB4kw3GtrniNSgK7NYzgAZqf5nKhUv4p9f0WkhqHMzhFtVu3ry3cdP1Jr
 tFUAqnfyZsZZy3NA8/YP7HaHILH0Eola/MeHzcSH+dVnxr8HgnoTLc9szjjAp8qBjy/u
 T15g==
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;
 bh=PIpPipEkxhvDuZjX0V8hFXSmkZraZsch/3nxDDh3bmk=;
 b=ABLjKnKlrqPBrIk/tw7CCnO3q8OByDLpyRvqJWugp5Lq7tIJwWp0RUxCunUhtJlglw
 Srx5LnrmzvEE51/h8VDi0Zk/+qvFrxDeQQGxLtBbXa4+NxwEEAtFe52s+3Ymuhj76hPS
 wmMlq2ND6h65woIN/Xqbjc493sR5bnnkl/r3ymBcq/CqdjBCZXDyKzjwHbM+n/36Qfmq
 SAtTEN/oLkixRQOFFNveVKyBS0cNSlNYE4rIbpRVEfKutMFaFU6z3VQCqA2KkYZFeCF4
 k66mjQkuWNbQqrFlY2egYn4RVHjnuguTckYXMRkfVmPNnixD8av83o9oOBD1xVsdNkIJ
 acAQ==
X-Gm-Message-State: AOAM532JUaCMFn+NF2j8hg1mXjL30zMwLxXUsJrrivhyewn6491x2jOO
 cqZr6D8HSFo/F4hcEVaPdpNHVqJazaFTlmce78PMj7IsdPBXhg==
X-Google-Smtp-Source: ABdhPJxcseMQdtE7xlg+VYnF11XsZDvIboGrBlHFuR0TzrmY/n68wHZWZSQghRAuwi1Cqwag03dN+6djORMV3RhqfaM=
X-Received: by 2002:ac8:7e8a:0:b0:2f1:ebd6:b28b with SMTP id
 w10-20020ac87e8a000000b002f1ebd6b28bmr17351284qtj.286.1650547353118; Thu, 21
 Apr 2022 06:22:33 -0700 (PDT)
MIME-Version: 1.0
References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
 <20220421050351.GA5616@erisian.com.au>
In-Reply-To: <20220421050351.GA5616@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 21 Apr 2022 09:22:21 -0400
Message-ID: <CAMZUoKnCzX6yNaMxaG_hZ1=w_Sa7NPZMbHM=oJ8WsB0sLYVcTw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aafd4805dd2a0020"
Subject: Re: [bitcoin-dev] CTV Signet Parameters
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, 21 Apr 2022 13:22:36 -0000

--000000000000aafd4805dd2a0020
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>  - is there really any benefit to doing it as a NOP vs a taproot-only
>    opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
>    was pointed out on #bitcoin-wizards the other day, you can't express
>    those outputs as an address, which makes them not very interoperable,
>    and if they're not interoperable between, say, an exchange and its
>    users trying to do a withdraw, how useful is that really ever going
>    to be?
>

FWIW, this is also approximately where my sticking point lies with BIP-119.

Overall I've come around to the idea of something like CTV.  The ability to
construct "smart contracts" that commit to *multiple* possible payout
schemes based on some conditions seems like a very useful construct, and
there have been several examples of  schemes proposed that use this feature.

However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
that bare-CTV hasn't even appeared on the CTV signet).  Unlike the general
smart-contracting case, bare-CTV does not have any branches.  All it can do
is commit to a subsequent transaction's outputs.  At first glance this
appears to be a waste because, for less bandwidth, that transaction could
just realize those outputs immediately, so why would anyone want to delay
the inevitable?

One reason might be that you want to commit to the output early during a
high-fee time, and then complete the transaction later during a low-fee
time.  While there are fee-rate situations where this could result in lower
fees than committing to the outputs all at once, it would be even cheaper
still to just wait to do the payout at the low-fee time.  I'm struggling to
understand the advantages of the advanced commitment, along with all the
overhead that entails.  Doesn't it just cause more blockspace to be used
overall?

There are some other proposed use cases for bare-CTV.  A bare-CTV can be
used to delay a "trigger"-transaction.  Some contracts, such as vaults, use
a relative-locktime as part of their construction and it could make sense
to make an output commitment but not realize those outputs yet until you
are ready to start your relative-time lock clock.  But bare-CTV doesn't
support any co-signing ability here, so you are relying entirely on keeping
the transaction data secret to prevent a third-party from triggering your
relative-lock clock.  More specifically for a vault scheme, since
bare-CTV's are currently unaddressable, and AFAIK, there is no address
format proposal yet, it is impossible to receive funds directly into a
vault.  You must shuffle received funds into your vault yourself, which
seems very likely to negate the cost savings of using bare-CTV in the first
place (please correct me if I'm wrong).  Better to receive funds directly
into a taproot-CTV vault, which has an address, and while you are at it,
you could place the cold-key as the taproot key to save even more when
using the cold-key to move vault funds.

There might be even more exotic use cases of bare-CTV.  For example you
could commit to a transaction that has a second input that doesn't yet
exist in the UTXO set in an attempt to coax it into existence. I don't know
if there have been any proposals to take advantage of this.

With that said, everything that bare-CTV can do, can also be done by
tapscript-CTV; so it is just a matter of cost.  I'm struggling to
understand where this cost savings is and how much those savings are going
to be given that bare-CTV is unaddressable and seems to ultimately occupy
more-blockspace than if the outputs were directly committed to.

I also believe the bare-CTV question is material, because if bare-CTV were
not part of the spec, then I'd be advocating for using an OP_SUCCESS code
from tapscript instead, and either use push-style semantics for CTV, which
would be composed with EQUAL_VERIFY to mimic the currently proposed
verification style-semantics, or a hybrid push-or-verify semantics that
would either push or verify depending on the size of the input.  (And I
still think a more general TXHASH would be even better, though if I cannot
convince aj then perhaps I'm wrong.)

I'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling
with its justification.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
<br>
=C2=A0- is there really any benefit to doing it as a NOP vs a taproot-only<=
br>
=C2=A0 =C2=A0opcode like TXHASH? Theoretically, sure, that saves some bytes=
; but as<br>
=C2=A0 =C2=A0was pointed out on #bitcoin-wizards the other day, you can&#39=
;t express<br>
=C2=A0 =C2=A0those outputs as an address, which makes them not very interop=
erable,<br>
=C2=A0 =C2=A0and if they&#39;re not interoperable between, say, an exchange=
 and its<br>
=C2=A0 =C2=A0users trying to do a withdraw, how useful is that really ever =
going<br>
=C2=A0 =C2=A0to be?<br></blockquote><div><br></div><div>FWIW, this is also =
approximately where my sticking point lies with BIP-119.</div><div><br></di=
v><div>Overall I&#39;ve come around to the idea of something like CTV.=C2=
=A0 The ability to construct &quot;smart contracts&quot; that commit to *mu=
ltiple* possible payout schemes based on some conditions seems like a very =
useful construct, and there have been several examples of=C2=A0 schemes pro=
posed that use this feature.<br></div><div><br></div><div>However, I&#39;m =
still skeptical of the bare-CTV part of BIP-119 (and I&#39;m told that bare=
-CTV hasn&#39;t even appeared on the CTV signet).=C2=A0 Unlike the general =
smart-contracting case, bare-CTV does not have any branches.=C2=A0 All it c=
an do is commit to a subsequent transaction&#39;s outputs.=C2=A0 At first g=
lance this appears to be a waste because, for less bandwidth, that transact=
ion could just realize those outputs immediately, so why would anyone want =
to delay the inevitable?<br></div><div><br></div><div>One reason might be t=
hat you want to commit to the output early during a high-fee time, and then=
 complete the transaction later during a low-fee time.=C2=A0 While there ar=
e fee-rate situations where this could result in lower fees than committing=
 to the outputs all at once, it would be even cheaper still to just wait to=
 do the payout at the low-fee time.=C2=A0 I&#39;m struggling to understand =
the advantages of the advanced commitment, along with all the overhead that=
 entails.=C2=A0 Doesn&#39;t it just cause more blockspace to be used overal=
l?</div><div><br></div><div>There are some other proposed use cases for bar=
e-CTV.=C2=A0 A bare-CTV can be used to delay a &quot;trigger&quot;-transact=
ion.=C2=A0 Some contracts, such as vaults, use a relative-locktime as part =
of their construction and it could make sense to make an output commitment =
but not realize those outputs yet until you are ready to start your relativ=
e-time lock clock.=C2=A0 But bare-CTV doesn&#39;t support any co-signing ab=
ility here, so you are relying entirely on keeping the transaction data sec=
ret to prevent a third-party from triggering your relative-lock clock.=C2=
=A0 More specifically for a vault scheme, since bare-CTV&#39;s are currentl=
y unaddressable, and AFAIK, there is no address format proposal yet, it is =
impossible to receive funds directly into a vault.=C2=A0 You must shuffle r=
eceived funds into your vault yourself, which seems very likely to negate t=
he cost savings of using bare-CTV in the first place (please correct me if =
I&#39;m wrong).=C2=A0 Better to receive funds directly into a taproot-CTV v=
ault, which has an address, and while you are at it, you could place the co=
ld-key as the taproot key to save even more when using the cold-key to move=
 vault funds.</div><div><br></div><div>There might be even more exotic use =
cases of bare-CTV.=C2=A0 For example you could commit to a transaction that=
 has a second input that doesn&#39;t yet exist in the UTXO set in an attemp=
t to coax it into existence. I don&#39;t know if there have been any propos=
als to take advantage of this.</div><div><br></div><div><div>With that said=
, everything that bare-CTV can do, can also be done by tapscript-CTV; so it=
 is just a matter of cost.=C2=A0 I&#39;m struggling to understand where thi=
s cost savings is and how much those savings are going to be given that bar=
e-CTV is unaddressable and seems to ultimately occupy more-blockspace than =
if the outputs were directly committed to.</div><div><br></div><div>I also =
believe the bare-CTV question is material, because if bare-CTV were not par=
t of the spec, then I&#39;d be advocating for using an OP_SUCCESS code from=
 tapscript instead, and either use push-style semantics for CTV, which woul=
d be composed with EQUAL_VERIFY to mimic the currently proposed verificatio=
n style-semantics, or a hybrid push-or-verify semantics that would either p=
ush or verify depending on the size of the input.=C2=A0 (And I still think =
a more general TXHASH would be even better, though if I cannot convince aj =
then perhaps I&#39;m wrong.)<br></div><div><br></div><div>I&#39;m not sayin=
g bare-CTV is necessarily a bad idea.=C2=A0 I&#39;m just struggling with it=
s justification.<br></div></div></div></div>

--000000000000aafd4805dd2a0020--