path: root/e5/15081ed6bcc85c4232dd2eb2501cda09ba9f7e

Return-Path: <nadav@shesek.info>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B6FF7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Apr 2022 05:08:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8DD5B41C1C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Apr 2022 05:08:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level: 
X-Spam-Status: No, score=0.278 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.975,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
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 rXGJrGKpAUrD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Apr 2022 05:08:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [IPv6:2607:f8b0:4864:20::131])
 by smtp4.osuosl.org (Postfix) with ESMTPS id EB69D41C1A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Apr 2022 05:08:44 +0000 (UTC)
Received: by mail-il1-x131.google.com with SMTP id k12so3318488ilv.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 22:08:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=nsBpfrouY+RFMrtv/sXQU0XQPn1ga9TEmJx3XsvQZLU=;
 b=JvK1kYmAxuLBFfa+sxewSfO9+//xpdcClKDtF/4iTauvLecdjogTl6pufvs3QkN/Fa
 a8ZzwQUE3akqwJwyTw5Hj5kWOP0fVMiOwpT9G4ymtVs11lizh4Cl/DK85HhzUzAuUefX
 jpSdvRz+Kg7Irgu/vnACSBIvL7X0zRyEQLWJw=
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=nsBpfrouY+RFMrtv/sXQU0XQPn1ga9TEmJx3XsvQZLU=;
 b=14PZg9R0NNrX6nYdksDPX5VCuvUa6oghr8HFeOdHrBJBdD1t/hAOxok/lQqHtK45fr
 DIyY0HnyRBBAvbUg0QDqGxJHaPbsQzThNEelStR6jPEx4dQH1sWpP1NmkAH4/Ze4e6yD
 AOBQ4UEJWwO7lX4k1b1hSxfsyNlx19cWZveaXJzcWA0H+SsPSsg3uTe3I7cNe3ZA0k3B
 LHD0YZLWprRt9HnIwASuISojxbkICNSMiC3++52SoTL5Pn5sFtJt6rANnNkpz2SCpXeD
 OVXt3LVL4XVXOGX+oIyD/eUaFw5IPhCgPlSHAvJGdivqlg+gXto5tQsywKxNDMY24xri
 UlZw==
X-Gm-Message-State: AOAM531P28HwFUF5v8tegcNHcr9U1VyXVlyQl0zmEh0lziO0yVO6IYr9
 175C/A9C+FkoUhpFyP8MVnrGqlNPWeCTvfrWeAh9Jg==
X-Google-Smtp-Source: ABdhPJxyx9frHi23MTGcHP/AkTM0wrZzSXjizlJMfRp4lv1nk4Es6gqvRnOuTtEPKsYpRcsexvRtl2Rk8VIf7uxbTC0=
X-Received: by 2002:a05:6e02:1cad:b0:2cb:f94c:2eab with SMTP id
 x13-20020a056e021cad00b002cbf94c2eabmr13705682ill.259.1651208923618; Thu, 28
 Apr 2022 22:08:43 -0700 (PDT)
MIME-Version: 1.0
References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
In-Reply-To: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 29 Apr 2022 08:08:32 +0300
Message-ID: <CAGXD5f3CyoRytWi4rsTUJocBS3Kqb=T2z6fOe+eORc-uxALrDg@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000057b74305ddc409de"
X-Mailman-Approved-At: Fri, 29 Apr 2022 07:13:13 +0000
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
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, 29 Apr 2022 05:08:46 -0000

--00000000000057b74305ddc409de
Content-Type: text/plain; charset="UTF-8"

Here's a summary of the trade-offs I see for using APO as a CTV alternative:

1. The resulting txids are not stable.

CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).

This property could be important for some of the proposed CTV use-cases,
like channel factories.

2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])

3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).

4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).

5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.

If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].

Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).

This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.

shesek

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128



On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Here&#39;s a summary of the trade-offs I see for usin=
g APO as a CTV alternative:</div><div></div><div><br></div><div>1. The resu=
lting txids are not stable.</div><div><br></div><div>CTV commits to enough =
tx information such that given the txid:vout of the covenant-encumbered out=
put, you can predict the txid of the spending tx permitted by CTV (and of t=
he entire transaction graph descending from it).<br></div><div><br></div><d=
iv>This property could be important for some of the proposed CTV use-cases,=
 like channel factories.</div><div></div><div><div><br></div><div><div>2. A=
PO will only be available on Taproot, which some people might prefer
 to avoid for long-term multi-decade vault storage due to QC concerns. (als=
o see my previous post on this thread [0])<br></div><div><br></div><div>3. =
Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot (pl=
us 33 extra vbytes vs CTV-in-segwitv0 <i>in the case of a single CTV branch=
</i>, for the taproot control block. with more branches CTV-in-taproot even=
tually becomes preferable).<br></div><div><br></div><div>4. Higher network-=
wide full-node validation costs (checking a signature is quite more expensi=
ve than hashing, and the hashing is done in both cases).</div><div><br></di=
v></div><div></div><div>5. As APO is currently spec&#39;d, it would suffer =
from the half-spend problem: if you=20
have multiple outputs encumbered under an APO covenant that requires the
 same tx sigmsg hash, it becomes possible to spend all of them together=20
as multiple inputs in a single transaction and burn the extra to mining=20
fees.</div><div><br></div><div><div>If I&#39;m not=20
mistaken, I believe this makes the simple-apo-vault implementation [1]=20
vulnerable to spending multiple vaulted outputs of the same denomination
 together and burning all but the first one. I asked the author for a=20
more definitive answer on twitter [2].</div><div><br></div><div>Fixing this=
 requires amending BIP 118 with some new sigmsg flags (making the ANYONECAN=
PAY behaviour optional, as mentioned in the OP).</div><div><br></div><div>T=
his is definitely possible but also means that APO as-is isn&#39;t a CTV-re=
placement candidate, without first going through some more design and revie=
w iterations.</div><div><br></div><div>shesek<br></div></div></div><div><br=
></div><div>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-April/020326.html">https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2022-April/020326.html</a></div><div></div><div>[1] <a href=3D=
"https://github.com/darosior/simple-anyprevout-vault">https://github.com/da=
rosior/simple-anyprevout-vault</a></div><div>[2] <a href=3D"https://twitter=
.com/shesek/status/1519874493434544128">https://twitter.com/shesek/status/1=
519874493434544128</a></div><div><br></div><div><br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 22, 2=
022 at 2:23 PM darosior via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<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">I would like=
 to know people&#39;s sentiment about doing (a very slightly tweaked versio=
n of) BIP118 in place of<br>
(or before doing) BIP119.<br>
<br>
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for ove=
r 6 years. It presents proven and<br>
implemented usecases, that are demanded and (please someone correct me if i=
&#39;m wrong) more widely accepted than<br>
CTV&#39;s.<br>
<br>
SIGHASH_ANYPREVOUTANYSCRIPT, if its &quot;ANYONECANPAY&quot; behaviour is m=
ade optional [0], can emulate CTV just fine.<br>
Sure then you can&#39;t have bare or Segwit v0 CTV, and it&#39;s a bit more=
 expensive to use. But we can consider CTV<br>
an optimization of APO-AS covenants.<br>
<br>
CTV advocates have been presenting vaults as the flagship usecase. Although=
 as someone who&#39;ve been trying to<br>
implement practical vaults for the past 2 years i doubt CTV is necessary no=
r sufficient for this (but still<br>
useful!), using APO-AS covers it. And it&#39;s not a couple dozen more virt=
ual bytes that are going to matter for<br>
a potential vault user.<br>
<br>
If after some time all of us who are currently dubious about CTV&#39;s stat=
ed usecases are proven wrong by onchain<br>
usage of a less efficient construction to achieve the same goal, we could r=
oll-out CTV as an optimization.=C2=A0 In<br>
the meantime others will have been able to deploy new applications leveragi=
ng ANYPREVOUT (Eltoo, blind<br>
statechains, etc..[1]).<br>
<br>
<br>
Given the interest in, and demand for, both simple covenants and better off=
chain protocols it seems to me that<br>
BIP118 is a soft fork candidate that could benefit more (if not most of) Bi=
tcoin users.<br>
Actually i&#39;d also be interested in knowing if people would oppose the A=
PO-AS part of BIP118, since it enables<br>
CTV&#39;s features, for the same reason they&#39;d oppose BIP119.<br>
<br>
<br>
[0] That is, to not commit to the other inputs of the transaction (via `sha=
_sequences` and maybe also<br>
`sha_amounts`). Cf <a href=3D"https://github.com/bitcoin/bips/blob/master/b=
ip-0118.mediawiki#signature-message" rel=3D"noreferrer" target=3D"_blank">h=
ttps://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-mes=
sage</a>.<br>
<br>
[1] <a href=3D"https://anyprevout.xyz/" rel=3D"noreferrer" target=3D"_blank=
">https://anyprevout.xyz/</a> &quot;Use Cases&quot; section<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>

--00000000000057b74305ddc409de--