From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <8d5251c8-9381-4f35-9d3e-19ba46c8b31cn@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 | , and you could have a an application-only versioning of the 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: | "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 | . > > 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,

> Applications already using annexes who want to al= so take advantage of
> new consensus features will of course have t= o upgrade their encoding
> schemes to match. But I think that's fin= e.

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 yo= u could
have a an application-only versioning of the <random_payloa= d_data> with
one more 1-byte, to give the evolvability to applicati= on to experiment
with multiple parsing format.

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

If it can be useful in any way, an old annex br= anch with a try of TLV:
https://github.com/ariard/bitcoin/commit/84a89= 7feb20c7df813e236d6bf98b69e241a4530

IMHO, this was a very positi= ve thing for taproot to have a lot of
versioning and upgradeability pa= ths (e.g leaves version, pubkey type, etc).

> There is a poss= ibility of a multi-party, annex-using, protocol where
> someone doe= s a pinning attack by re-signing their transaction with a
> bigger = annex. But witness-RBF in combination with replace-by-fee-rate
> wi= ll fix this, so I'm not concerned. No such protocols actually exist
&g= t; 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 thin= k it works for multi-party protocols.

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

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

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 disting= uish them
> > from consensus-relevant annexes. This ensures that any use of= the
> > annex will not conflict with future soft-forks that may assig= n
> > 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 schem= e
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 ann= ex 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 a= voids
> the kind of issue, like what if the annex size is inflated to down= grade
> 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 the
> annex, to avoid the same concern than above. There shouldn't b= e max
> limit for now, as normally the annex is not standard at all as a t= aproot
> 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 exi= st
yet anyway, so we can figure that out later.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

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