path: root/a3/0a076b4291f6f0d0d2214d0773de05262adbd7

Delivery-date: Sun, 23 Mar 2025 18:30:17 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBH7LQK7QMGQE3ZARUNQ@googlegroups.com>)
	id 1twWds-000349-7K
	for bitcoindev@gnusha.org; Sun, 23 Mar 2025 18:30:17 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e6345bc7bd7sf6357706276.0
        for <bitcoindev@gnusha.org>; Sun, 23 Mar 2025 18:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742779810; x=1743384610; 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=O76Wc/E5I8sGUVfN3+LCY14sAcbhvwSnLib6VdDuBsc=;
        b=rWa+FoFzWGJscwojIgnfV9det8usGsOdSIdlZUUu8eGIlTpuYrb0GNlKBRtmvWFBau
         AiAqf4GDOzPLVnPA4HPOgFy6BduwH3lmNQq/QEJIrtNDygvQs6aLMuQ1MUYuZpz2jtd4
         2qFRUx9JC/A//+7kP7eliY4CkwueRkCY1O8Fz4P1V9zrdoC/bj713G9LfyCb8JeJIeR8
         TYxNdgRRtirphxWN5VtIIf4zImyslaKQUXCn4RbndIngq5Y5KQtb0P5pufsByOLUSQ1B
         r8ypTer/XwJDyLZhSIZXOJPF72DhyU/IK61owI0ZvaUHIxixFlW4iTZCVAWfkawSJm02
         MGbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742779810; x=1743384610; 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=O76Wc/E5I8sGUVfN3+LCY14sAcbhvwSnLib6VdDuBsc=;
        b=ApA9Mh3PAuRWfxy8R32Q5jhxXwO+m57vfsxTLIZKDahm3t9xWmmjdRhbioBLq2t40K
         q/ptgA29niXdrFNdMTwB0rotljzOiaae+DOBMTxXbtx6NOUyPqoluY+jjiuu5bgRCYLh
         c3ZfAuX5rpWvJ1NHgSg5DY4ubSQVew1SawrZADuNgusjSd2Mx2Qhjs+S7Iw7Nhn+/0wv
         a/8mA9ahu7krbnwyHEwL8n8kwBKoKdDYkCTLiLQ6NRSevz/tco2fEgXFI7PSUpVX//AL
         veXgT1PgPzWYFl9QJRkYxUe+ZO+mdgHOh5P2XF7lk8rV5DiNZVH0Ew7dlsK9OK2mfC0C
         k0Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742779810; x=1743384610;
        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=O76Wc/E5I8sGUVfN3+LCY14sAcbhvwSnLib6VdDuBsc=;
        b=OZv/+FFiJ3g/3Jd0eQ2zWm3csaxxjH6gZqR6QVMKGvcIj612RziCFtRJMrcIt7b+bC
         oAVEeqOoRdhtEmu5JxaLe2VRR/R2Qio9zXCBC2xBcf+tqBUATYVAguqE5iRfaPx/f2b8
         OnXI9DQ/rVKE+VOCC1UHYD0PJjSPDnIfXRaaUfQsizACvHvtpjA2vveWQru144BAB6NB
         JJjysH4GSbZRU7LPfTbjHVs8guG7kl/1c/pjnOgy4uhut1H1zTQEwFSP+wsF73K9hbeI
         Sh4zRZ0w5soY0xgW/uRQqlCcquYuRo9/yGZozbbdxILvBcqLNL9nSMyVDXf5+X6GrIgb
         ltsg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXY8FCiWHPnf6s9JNU7RpLrdQGtStV+NbR0MYkpOQSf5Xa5tIjbRB/ixAJTjAxkhue06iX9Gf/nar0S@gnusha.org
X-Gm-Message-State: AOJu0YwcI2bHThR0En0xUL6UGYK9hAqlb85fqE8Wb82l6V66ox9ZwZq7
	HVjtToEKtRRHLomSH/5NS+1AF+SrItIcXgmcE/4OBbB0g5IC7Ytx
X-Google-Smtp-Source: AGHT+IHOhMdutVwFXc9Rdix8BnzUPsreTNqbsXQmvdHRNz5qw49KTzb5thdJl8Hk61mT6dHcm0c75A==
X-Received: by 2002:a05:6902:480d:b0:e63:6987:6e61 with SMTP id 3f1490d57ef6-e66a31f35c0mr16563723276.10.1742779810253;
        Sun, 23 Mar 2025 18:30:10 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJ67erlUDlbLhBXH2SjouoMSU20P8Ral8sjF1ia8UWbfw==
Received: by 2002:a5b:20f:0:b0:e61:1c4c:6d6b with SMTP id 3f1490d57ef6-e6690a82f1dls51798276.2.-pod-prod-02-us;
 Sun, 23 Mar 2025 18:30:07 -0700 (PDT)
X-Received: by 2002:a05:690c:350d:b0:6fd:4849:62da with SMTP id 00721157ae682-700bac62a51mr135689617b3.22.1742779807073;
        Sun, 23 Mar 2025 18:30:07 -0700 (PDT)
Received: by 2002:a81:a947:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-700ba2435b7ms7b3;
        Thu, 20 Mar 2025 15:47:18 -0700 (PDT)
X-Received: by 2002:a05:690c:4507:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-700bad190b5mr15254427b3.23.1742510836442;
        Thu, 20 Mar 2025 15:47:16 -0700 (PDT)
Date: Thu, 20 Mar 2025 15:47:16 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d906eece-2edb-428c-8d67-3836d52f4897n@googlegroups.com>
In-Reply-To: <Z9tg-NbTNnYciSOh@petertodd.org>
References: <Z9tg-NbTNnYciSOh@petertodd.org>
Subject: [bitcoindev] Re: Standard Unstructured Annex
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_19968_1216546541.1742510836180"
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_19968_1216546541.1742510836180
Content-Type: multipart/alternative; 
	boundary="----=_Part_19969_338050350.1742510836180"

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

Hi Peter,

See also that can be relevant for taproot annex support:
https://github.com/bitcoin/bips/pull/1381

> 1) All non-empty annexes start with the byte 0x00, to distinguish them
> 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.

So IIUC, it would be 1-byte: 0x00 | <random_data payload>.

> 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.

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).

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 be max
limit for now, as normally the annex is not standard at all as a taproot
data field.

Best,
Antoine
OTS hash: 5b620c444896f05d05fe00542a4ac04c44f21684
Le jeudi 20 mars 2025 =C3=A0 01:02:10 UTC, Peter Todd a =C3=A9crit :

> I'm working on adding support for the taproot annex to Libre Relay:
>
>
> https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e048bf5751d1359=
2a22763ff7e
>
> I'm basing this on Joost Jager's pull-req:=20
> https://github.com/bitcoin/bitcoin/pull/27926
>
> Specifically, transactions containing taproot annexes will be standard
> if:
>
> 1) All non-empty annexes start with the byte 0x00, to distinguish them
> 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.
>
> 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.
>
> An example of a transaction meeting these requirements is:
>
>
> 010000000001011a559447098aaa14dec0c62ea55f43f9ce6bda07d1759f11b634334ab9d=
a939b0000000000ffffffff010000000000000000076a05616e6e657802406840b6fa27a00b=
a001cc92797ce4f3ab7b7a32c21d1fce49e893b42e506bd92e8db187966a84ef799915cf671=
334cc59779915b192bfb66b2afcf384bb61d0f422500049276d20616e20616e6e6578212041=
726520796f7520616e20616e6e65783f0000000000
>
> --=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/=
d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com.

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

Hi Peter,<br /><br />See also that can be relevant for taproot annex suppor=
t:<br />https://github.com/bitcoin/bips/pull/1381<br /><br />&gt; 1) All no=
n-empty annexes start with the byte 0x00, to distinguish them<br />&gt; fro=
m consensus-relevant annexes. This ensures that any use of the<br />&gt; an=
nex will not conflict with future soft-forks that may assign<br />&gt; mean=
ing to the annex.<br /><br />So IIUC, it would be 1-byte: 0x00 | &lt;random=
_data payload&gt;.<br /><br />&gt; 2) All inputs have an annex. This ensure=
s that use of the annex is<br />&gt; opt-in, preventing transaction pinning=
 attacks in multi-party<br />&gt; protocols. This requirement may be relaxe=
d in the future, eg to allow<br />&gt; spends of keyless outputs, and/or if=
 RBF for witness-only<br />&gt; replacements is implemented.<br /><br />I t=
hink it's good to start with all inputs have an annex. It avoids<br />the k=
ind of issue, like what if the annex size is inflated to downgrade<br />the=
 feerate of the multi-party transaction (e.g to have a coinjoin<br />stucki=
ng in network mempools).<br /><br />One thing that might be missed, without=
 having looked to the code, is<br />potentially a policy transaction-relay =
rule to limit the max size of the<br />annex, to avoid the same concern tha=
n above. There shouldn't be max<br />limit for now, as normally the annex i=
s not standard at all as a taproot<br />data field.<br /><br />Best,<br />A=
ntoine<br />OTS hash: 5b620c444896f05d05fe00542a4ac04c44f21684<br /><div cl=
ass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le jeudi 20 mars=
 2025 =C3=A0 01:02:10 UTC, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">I&#39;m working on adding supp=
ort for the taproot annex to Libre Relay:
<br>
<br><a href=3D"https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e0=
48bf5751d13592a22763ff7e" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/pet=
ertodd/bitcoin/commit/04c8e449a34e74e048bf5751d13592a22763ff7e&amp;source=
=3Dgmail&amp;ust=3D1742597172176000&amp;usg=3DAOvVaw1ZApO8er4UoxBgvjqHNCnv"=
>https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e048bf5751d13592=
a22763ff7e</a>
<br>
<br>I&#39;m basing this on Joost Jager&#39;s pull-req: <a href=3D"https://g=
ithub.com/bitcoin/bitcoin/pull/27926" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gi=
thub.com/bitcoin/bitcoin/pull/27926&amp;source=3Dgmail&amp;ust=3D1742597172=
176000&amp;usg=3DAOvVaw3NBOE7rT47DCctsmiAmKxf">https://github.com/bitcoin/b=
itcoin/pull/27926</a>
<br>
<br>Specifically, transactions containing taproot annexes will be standard
<br>if:
<br>
<br>1) All non-empty annexes start with the byte 0x00, to distinguish them
<br>   from consensus-relevant annexes. This ensures that any use of the
<br>   annex will not conflict with future soft-forks that may assign
<br>   meaning to the annex.
<br>
<br>2) All inputs have an annex. This ensures that use of the annex is
<br>   opt-in, preventing transaction pinning attacks in multi-party
<br>   protocols. This requirement may be relaxed in the future, eg to allo=
w
<br>   spends of keyless outputs, and/or if RBF for witness-only
<br>   replacements is implemented.
<br>
<br>An example of a transaction meeting these requirements is:
<br>
<br>010000000001011a559447098aaa14dec0c62ea55f43f9ce6bda07d1759f11b634334ab=
9da939b0000000000ffffffff010000000000000000076a05616e6e657802406840b6fa27a0=
0ba001cc92797ce4f3ab7b7a32c21d1fce49e893b42e506bd92e8db187966a84ef799915cf6=
71334cc59779915b192bfb66b2afcf384bb61d0f422500049276d20616e20616e6e65782120=
41726520796f7520616e20616e6e65783f0000000000
<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=3D1742597172176000&amp;usg=3DAOvVaw3=
NIc9qw2c6r3kNa0tlsqvu">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=3D1742597172176000&amp;usg=3DAOvVaw1J8LUZ-r9Edu=
HgzAIAhnP3">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/d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com</a>.<br />

------=_Part_19969_338050350.1742510836180--

------=_Part_19968_1216546541.1742510836180--