path: root/bf/1f8dccd6bf5a8f894ce0631191b9bd533537a4

Delivery-date: Wed, 09 Apr 2025 16:24:42 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBL4D3S7QMGQEHTSBCLI@googlegroups.com>)
	id 1u2emf-0000Ok-Ha
	for bitcoindev@gnusha.org; Wed, 09 Apr 2025 16:24:42 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e64124940absf349785276.3
        for <bitcoindev@gnusha.org>; Wed, 09 Apr 2025 16:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744241075; x=1744845875; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=uFXmhBBUBtRBL27djzumAtfA4GZEBNlonkdoxLp0BIE=;
        b=jbyrXzXY7EKf4+as9ENlGTVizeeV/0cVnQn9YAOeqGROhwAZqncNilGLrnYrkoF5Su
         4yaifUCNFLoGhZ34CA3HFgWAKSrh1RlepUIzGYxn/UsSGMGSvtRL39wftlJptRG8MBBH
         AbrE2uGnz3Rw0mXXDmsSg9/tts4jpztwKixjD6pLhI6bfgI+GNCltbJEc1SXyx2yv6Vi
         y9FlQGEjPrdq6/n/NuX/vYoK4Diz8tj3uorFY5bZwdBD2sMQnXQcgmke/CRA0Kip0uD/
         nc3hKUM64dHAki+jT0gsPXz9ZNgcAWjIINsmWqshJO45KFlm1K5qJklfpoeTHoGpGLdD
         ZSWQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1744241075; x=1744845875; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uFXmhBBUBtRBL27djzumAtfA4GZEBNlonkdoxLp0BIE=;
        b=K2wWeVojjLL6QO6nfbB1F/tYYRPItDIMP1eBdY+OuZT8P5Swi0GKLk/QRj4RNbbHL2
         9mrcMUTsZVVcykTwEJfbJlMmICtUx/FaXUkTbTCb2NfxiQ6ZaJSI1uozpzqQFSqnnqIn
         hKojeMpriREyFQ1Vh2O+Vx+PtpMRK1JkkeeO82nKnXXesjhz9essTdnSUUvjcJYP127T
         GiceMjmF9+NsA/MzgHf0vfLRg6x7xWVSfeZIwOfvtrZqWUmVyShxH5oG/YrCkTtQUu0B
         FcsbyQHlk+AHUGKbfnGWhyH2Ckc8yhce2yPLn0PUslfjLtplLrRUCWg3Vjj1cbjlYST6
         YO1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744241075; x=1744845875;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uFXmhBBUBtRBL27djzumAtfA4GZEBNlonkdoxLp0BIE=;
        b=l5BrDR+SOFSj5/zPEuDPZi/+7Te7rrwhiTj+NNi4EMRT7nD04uMoJsbAM6qPlY3OQ4
         YhprDpDQjKzsA8fAcyK2ItyC6VbM5O8iIaRpGI2iiLZBsWXvKbdKVNDLKMov26wmIih0
         Cj9uFxhIk5jWnB+qHQ0zGqwuEzGmrKt8btqr24d9mWTtfbE4rcRsHOjKqEAOanER1l0U
         YRKWivHkXKrHpGdWf+2/ESUfJPzwo8BI0I5WBfB5r2QAMvH2ESnJ9zfZoQarEUtKIrDj
         9XEf8HVVIeORu8etuy33ul4VSxHxosXRx/B8zuRh5uRA3GQVXIBQ1rpPpaT8jnO1NBus
         UaUg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVn9v+T/e/Etteqpu/nYGa+TtQiWDYR3U1sjUVLaP45S73ExqoAH9zpRtzQ42F+DzYDgZ8wjQ3qBa38@gnusha.org
X-Gm-Message-State: AOJu0Yzqt5koiE1S7v9fceTiaJpnQ1zELNHEhIjVeUG8HDtbh0mgN+px
	cS5mRB7AvUV7VRYv1js8Dk+QWhGyoHQIdrnPNnwh3z97KUPRb8rj
X-Google-Smtp-Source: AGHT+IF9OKMHvTNMcKZtj3Q7mhPo5od8C1t6fWO+LAJhlhC/s0gxlNuOi8IcjuNYnLbXPKvHt/0TXA==
X-Received: by 2002:a05:6902:4811:b0:e6d:ee69:dd3e with SMTP id 3f1490d57ef6-e703fc7ede7mr448543276.47.1744241075059;
        Wed, 09 Apr 2025 16:24:35 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJyOeZydepbPJ6JFgW9IogMbfinpxlfvT9jJ4Rw6nAZJA==
Received: by 2002:a25:2d19:0:b0:e6d:e007:ed3b with SMTP id 3f1490d57ef6-e703c5fc367ls458165276.2.-pod-prod-05-us;
 Wed, 09 Apr 2025 16:24:30 -0700 (PDT)
X-Received: by 2002:a05:690c:4c13:b0:6f9:776f:71d7 with SMTP id 00721157ae682-70549ecc533mr8795937b3.21.1744241070744;
        Wed, 09 Apr 2025 16:24:30 -0700 (PDT)
Received: by 2002:a05:690c:248:b0:703:d6cc:4806 with SMTP id 00721157ae682-70539a44faems7b3;
        Wed, 9 Apr 2025 15:55:59 -0700 (PDT)
X-Received: by 2002:a05:690c:4c0f:b0:6f9:a3c6:b2e4 with SMTP id 00721157ae682-7054a179143mr9007107b3.37.1744239358265;
        Wed, 09 Apr 2025 15:55:58 -0700 (PDT)
Date: Wed, 9 Apr 2025 15:55:58 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <8d5251c8-9381-4f35-9d3e-19ba46c8b31cn@googlegroups.com>
In-Reply-To: <Z-GFqu7bfDGdLSa-@petertodd.org>
References: <Z9tg-NbTNnYciSOh@petertodd.org>
 <d906eece-2edb-428c-8d67-3836d52f4897n@googlegroups.com>
 <Z-GFqu7bfDGdLSa-@petertodd.org>
Subject: Re: [bitcoindev] Re: Standard Unstructured Annex
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_85014_2111740540.1744239358006"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_85014_2111740540.1744239358006
Content-Type: multipart/alternative; 
	boundary="----=_Part_85015_594884505.1744239358006"

------=_Part_85015_594884505.1744239358006
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> Applications already using annexes who want to also take advantage of
> new consensus features will of course have to upgrade their encoding
> schemes to match. But I think that's fine.

Yes, I agree. I believe there is one more thing to falicitate any future
potential encoding scheme transition for application.

I.e you have the 1-byte : 0x00 | <random_payload_data>, and you could
have a an application-only versioning of the <random_payload_data> with
one more 1-byte, to give the evolvability to application to experiment
with multiple parsing format.

So you would have "1-byte" 0x00 | "random_payload_data" where=20
"random_payload_data"
is defined as 1-byte: <version_number> | "random_payload_data". That
version number shall only have application meaning, no consensus, it's
just some kind of clear domain separation. AFAICT, the version number
could be always retrofitted for a non-0x00 tag-length-value consensus
meaning.

If it can be useful in any way, an old annex branch with a try of TLV:
https://github.com/ariard/bitcoin/commit/84a897feb20c7df813e236d6bf98b69e24=
1a4530

IMHO, this was a very positive thing for taproot to have a lot of
versioning and upgradeability paths (e.g leaves version, pubkey type, etc).

> There is a possibility of a multi-party, annex-using, protocol where
> someone does a pinning attack by re-signing their transaction with a
> bigger annex. But witness-RBF in combination with replace-by-fee-rate
> will fix this, so I'm not concerned. No such protocols actually exist
> yet anyway, so we can figure that out later.

Correct given it's opt-in and that there will be witness-RBF support.

Note, for witness support, where IIUC you have wtxidB allowed to
replace wtxidB if wtxidA's feerate > wtxidB and if annex size is
unbounded, I think it works for multi-party protocols.

For witness re-composition problems, see:
https://github.com/bitcoin/bitcoin/pull/19645#issuecomment-677955391

Best,
Antoine
OTS hash: 30c270434ccb4b50a4a65b40bcdc014b8ef863df8e5e425732c1b385e71b680c
Le lundi 24 mars 2025 =C3=A0 22:00:51 UTC, Peter Todd a =C3=A9crit :

>
> On Thu, Mar 20, 2025 at 03:47:16PM -0700, Antoine Riard wrote:
> > Hi Peter,
> >=20
> > See also that can be relevant for taproot annex support:
> > https://github.com/bitcoin/bips/pull/1381
>
> Thanks.
>
> > > 1) All non-empty annexes start with the byte 0x00, to distinguish the=
m
> > > from consensus-relevant annexes. This ensures that any use of the
> > > annex will not conflict with future soft-forks that may assign
> > > meaning to the annex.
> >=20
> > So IIUC, it would be 1-byte: 0x00 | <random_data payload>.
>
> Correct.
>
> When annex data finally does get a consensus meaning any encoding scheme
> starting with a non-zero byte will be compatible. Most likely we'll get
> some tag-length-value encoding scheme.
>
> Applications already using annexes who want to also take advantage of
> new consensus features will of course have to upgrade their encoding
> schemes to match. But I think that's fine.
>
> > > 2) All inputs have an annex. This ensures that use of the annex is
> > > opt-in, preventing transaction pinning attacks in multi-party
> > > protocols. This requirement may be relaxed in the future, eg to allow
> > > spends of keyless outputs, and/or if RBF for witness-only
> > > replacements is implemented.
> >=20
> > I think it's good to start with all inputs have an annex. It avoids
> > the kind of issue, like what if the annex size is inflated to downgrade
> > the feerate of the multi-party transaction (e.g to have a coinjoin
> > stucking in network mempools).
>
> Glad to hear you agree.
>
> > One thing that might be missed, without having looked to the code, is
> > potentially a policy transaction-relay rule to limit the max size of th=
e
> > annex, to avoid the same concern than above. There shouldn't be max
> > limit for now, as normally the annex is not standard at all as a taproo=
t
> > data field.
>
> Libre Relay has no limit on OP_Return output size; I'm not going to
> artificially limit annex usage either. The requirement to opt-in to
> annex usage should be sufficient.
>
> There is a possibility of a multi-party, annex-using, protocol where
> someone does a pinning attack by re-signing their transaction with a
> bigger annex. But witness-RBF in combination with replace-by-fee-rate
> will fix this, so I'm not concerned. No such protocols actually exist
> yet anyway, so we can figure that out later.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
8d5251c8-9381-4f35-9d3e-19ba46c8b31cn%40googlegroups.com.

------=_Part_85015_594884505.1744239358006
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<br /><br />&gt; Applications already using annexes who want to al=
so take advantage of<br />&gt; new consensus features will of course have t=
o upgrade their encoding<br />&gt; schemes to match. But I think that's fin=
e.<br /><br />Yes, I agree. I believe there is one more thing to falicitate=
 any future<br />potential encoding scheme transition for application.<br /=
><br />I.e you have the 1-byte : 0x00 | &lt;random_payload_data&gt;, and yo=
u could<br />have a an application-only versioning of the &lt;random_payloa=
d_data&gt; with<br />one more 1-byte, to give the evolvability to applicati=
on to experiment<br />with multiple parsing format.<br /><br />So you would=
 have "1-byte" 0x00 | "random_payload_data" where "random_payload_data"<br =
/>is defined as 1-byte: &lt;version_number&gt; | "random_payload_data". Tha=
t<br />version number shall only have application meaning, no consensus, it=
's<br />just some kind of clear domain separation. AFAICT, the version numb=
er<br />could be always retrofitted for a non-0x00 tag-length-value consens=
us<br />meaning.<br /><br />If it can be useful in any way, an old annex br=
anch with a try of TLV:<br />https://github.com/ariard/bitcoin/commit/84a89=
7feb20c7df813e236d6bf98b69e241a4530<br /><br />IMHO, this was a very positi=
ve thing for taproot to have a lot of<br />versioning and upgradeability pa=
ths (e.g leaves version, pubkey type, etc).<br /><br />&gt; There is a poss=
ibility of a multi-party, annex-using, protocol where<br />&gt; someone doe=
s a pinning attack by re-signing their transaction with a<br />&gt; bigger =
annex. But witness-RBF in combination with replace-by-fee-rate<br />&gt; wi=
ll fix this, so I'm not concerned. No such protocols actually exist<br />&g=
t; yet anyway, so we can figure that out later.<br /><br />Correct given it=
's opt-in and that there will be witness-RBF support.<br /><br />Note, for =
witness support, where IIUC you have wtxidB allowed to<br />replace wtxidB =
if wtxidA's feerate &gt; wtxidB and if annex size is<br />unbounded, I thin=
k it works for multi-party protocols.<br /><br />For witness re-composition=
 problems, see:<br />https://github.com/bitcoin/bitcoin/pull/19645#issuecom=
ment-677955391<br /><br />Best,<br />Antoine<br />OTS hash: 30c270434ccb4b5=
0a4a65b40bcdc014b8ef863df8e5e425732c1b385e71b680c<br /><div class=3D"gmail_=
quote"><div dir=3D"auto" class=3D"gmail_attr">Le lundi 24 mars 2025 =C3=A0 =
22:00:51 UTC, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">
<br>On Thu, Mar 20, 2025 at 03:47:16PM -0700, Antoine Riard wrote:
<br>&gt; Hi Peter,
<br>&gt;=20
<br>&gt; See also that can be relevant for taproot annex support:
<br>&gt; <a href=3D"https://github.com/bitcoin/bips/pull/1381" target=3D"_b=
lank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?h=
l=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bips/pull/1381&amp;source=3Dgmail=
&amp;ust=3D1744325695539000&amp;usg=3DAOvVaw28fDYjXGi47a_fYrT0ginb">https:/=
/github.com/bitcoin/bips/pull/1381</a>
<br>
<br>Thanks.
<br>
<br>&gt; &gt; 1) All non-empty annexes start with the byte 0x00, to disting=
uish them
<br>&gt; &gt; from consensus-relevant annexes. This ensures that any use of=
 the
<br>&gt; &gt; annex will not conflict with future soft-forks that may assig=
n
<br>&gt; &gt; meaning to the annex.
<br>&gt;=20
<br>&gt; So IIUC, it would be 1-byte: 0x00 | &lt;random_data payload&gt;.
<br>
<br>Correct.
<br>
<br>When annex data finally does get a consensus meaning any encoding schem=
e
<br>starting with a non-zero byte will be compatible. Most likely we&#39;ll=
 get
<br>some tag-length-value encoding scheme.
<br>
<br>Applications already using annexes who want to also take advantage of
<br>new consensus features will of course have to upgrade their encoding
<br>schemes to match. But I think that&#39;s fine.
<br>
<br>&gt; &gt; 2) All inputs have an annex. This ensures that use of the ann=
ex is
<br>&gt; &gt; opt-in, preventing transaction pinning attacks in multi-party
<br>&gt; &gt; protocols. This requirement may be relaxed in the future, eg =
to allow
<br>&gt; &gt; spends of keyless outputs, and/or if RBF for witness-only
<br>&gt; &gt; replacements is implemented.
<br>&gt;=20
<br>&gt; I think it&#39;s good to start with all inputs have an annex. It a=
voids
<br>&gt; the kind of issue, like what if the annex size is inflated to down=
grade
<br>&gt; the feerate of the multi-party transaction (e.g to have a coinjoin
<br>&gt; stucking in network mempools).
<br>
<br>Glad to hear you agree.
<br>
<br>&gt; One thing that might be missed, without having looked to the code,=
 is
<br>&gt; potentially a policy transaction-relay rule to limit the max size =
of the
<br>&gt; annex, to avoid the same concern than above. There shouldn&#39;t b=
e max
<br>&gt; limit for now, as normally the annex is not standard at all as a t=
aproot
<br>&gt; data field.
<br>
<br>Libre Relay has no limit on OP_Return output size; I&#39;m not going to
<br>artificially limit annex usage either. The requirement to opt-in to
<br>annex usage should be sufficient.
<br>
<br>There is a possibility of a multi-party, annex-using, protocol where
<br>someone does a pinning attack by re-signing their transaction with a
<br>bigger annex. But witness-RBF in combination with replace-by-fee-rate
<br>will fix this, so I&#39;m not concerned. No such protocols actually exi=
st
<br>yet anyway, so we can figure that out later.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1744325695539000&amp;usg=3DAOvVaw3=
hB_PmHoLMHXIjmY1K-M_v">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1744325695539000&amp;usg=3DAOvVaw0srAZSqja8Dr=
Ea1yoxlhzG">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8d5251c8-9381-4f35-9d3e-19ba46c8b31cn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/8d5251c8-9381-4f35-9d3e-19ba46c8b31cn%40googlegroups.com</a>.<br />

------=_Part_85015_594884505.1744239358006--

------=_Part_85014_2111740540.1744239358006--