MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
 <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>
 <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
In-Reply-To: <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 12 Jun 2023 04:16:44 +0100
Message-ID: <CALZpt+EXY6EjrC_mtZLe--ZrnycVdARG8eK6qvqaExA4t+EsQA@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009c975405fde6267a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

--0000000000009c975405fde6267a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Joost,

> However, the primary advantage I see in the annex is that its data isn't
included in the calculation of the txid or a potential parent commit
transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would
ideally use covenants.

I share the observation that the annex data not being committed in the
parent txid is very powerful for use-cases that would use covenants. E.g
there could be an alternative design of CoinPool based on Grafroot, where
the signed surrogate scripts authorized withdrawal abilities [0]. Once
consumed the signed surrogate shouldn't be replayable against the clawback
pool output, and the signature of the surrogate added as "toxic" in a
cryptographic accumulator. Efficient set test membership can be realized to
refuse pool output spend attempts with consumed surrogate scripts.

The annex is a perfect emplacement to locate such an accumulator in the
future as the state of the accumulator cannot be predicted as pool setup
time and is a function of the effective order withdrawal.

Note with Taproot-based design, the replay protection is achieved by the
removal from the taproot tree as edited by any contracting primitive during
the withdrawal phase (e.g TLUV).

> When it comes to the trade-offs associated with various encodings, I
fully acknowledge their existence. The primary motivation behind my
proposal to adopt a simple approach to the Taproot annex is to
> avoid a potentially long standardization process. While I am not entirely
familiar with the decision-making process of Bitcoin Core, my experience
with other projects suggests that simpler changes often
> encounter less resistance and can be implemented more swiftly. Perhaps I
am being overly cautious here, though.

I fully understand the motivation to avoid a lengthy standardization
process, which can be a source of frustration for everyone, including the
standard champions themselves. Indeed, no one lacks the bureaucratic-style
of standardization process for their own sake.

Long standardization processes in Bitcoin consensus are better explained by
the number of technical dimensions to weigh in terms of designs (e.g
full-nodes ressources scalability, fee economic costs, confidentiality,
composability with other changes). And due to the asynchronous nature of
FOSS development, every domain expert is constantly jungling between
different engineering contributions priorities (e.g for myself currently
package relay and mempool for L2s).

All that said, to make the conversation of annex standardization more
practical, and aiming to compose with all technical interest expressed, I
can think about a 2 phase process, at least.

Such standardization process reflects only my opinion, and is based on the
experience of recent mempool fullrbf partial deployment experience, the
Core's trends to have tracking issues for substantial changes,
bitcoin-inquisition and the bitcoin contracting primitives WG experiences.

Phase 1:
- a BIP proposal for the TLV records + code (almost done with #9 in
bitcoin-inquisition and #1421 in the bips repository)
- a BIP proposal to reserve "tag 0" for unstructured data + code (let's say
in bitcoin-inquisition)
- anti-DoS mempool/transaction-relay/replacement code (same)
- bonus point: documenting the new mempool/replacement rules like in Core's
`doc/policy`
- preferential peering logic working code (there is already some code with
Core's #25600)
- opt-in activation of the annex validation rules
- engage Bitcoin devs appreciated by the community as domain experts in the
covered areas to collect more relevant technical feedbacks

Phase 2:
- submit the annex branch with all the features on the Bitcoin Core
repository
- communicate to the Bitcoin technical community at large the existence of
the proposal e.g dev mail list, technical newsletters
- communicate to the second-layers and unstructured data application
maintainers the existence of the proposal
- integrate the feedback from Bitcoin Core, Bitcoin users and second-layers
communities in a "staging code branch"
- if there is a deep technical objection, go back to phase 1 (e.g a
competing serializing proposal for the annex)
- otherwise, split the annex reference branch core in logical chunks for
optimal review process

This is what an efficient-yet-decentralized standardization process of the
annex would look like to me, I don't know. About when we can expect a
deployment of new policy rules for the annex, as Dave made me the
(grounded) reprimand on the list a while back, I don't think mentioning a
date or software version release is appropriate. And this to avoid creating
a sense of commitment on all the contributors involved in the projects
above mentioned.

I'm still interested in championing the "base" TLV serialization annex code
and BIP. To move faster, I think it would be better to have another
champion on the "tag 0" and BIP, especially as the unstructured data
use-cases are coming with their own specifics.

> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witnesses
would provide a viable solution?

To be honest, in terms of DoS, I wouldn't give a strong opinion before
better formalization or consensus of the use-case requirements. From
experience of Core's mempools PRs, you have few subcomponents that can be
involved (replacement, block template, broadcast backend of L2s, etc).

> That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay
> transactions to miners besides the p2p network?

Assuming an alternative p2p network, I don't think we can avoid some
standardization of fundamental data structures between those p2p network.
Most of L2s are pre-signing transactions/packages and might not be able to
alter the validity of such set of transactions in a unilateral fashion
without re-introducing some =E2=80=9Cbad=E2=80=9D malleability. And a L2 no=
de has an
interest to use multiple p2p networks to mitigate against things like
time-dilation attacks.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01570=
0.html

Le dim. 11 juin 2023 =C3=A0 20:26, Joost Jager <joost.jager@gmail.com> a =
=C3=A9crit :

> Hi Dave,
>
> On Sun, Jun 11, 2023 at 12:10=E2=80=AFAM David A. Harding <dave@dtrt.org>=
 wrote:
>
>> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>>     #1 and pushes a serialized partial signature for the ephemeral key
>>     from #2 onto the stack, where it's immediately dropped by the
>>     interpreter (but is permanently stored on the block chain).  She als=
o
>>     attaches a regular signature for the OP_CHECKSIG opcode.
>>
>
> Isn't it the case that that op-dropped partial signature for the ephemera=
l
> key isn't committed to and thus can be modified by anyone before it is
> mined, effectively deleting the keys to the vault? If not, this would be =
a
> great alternative!
>
> Even better, I think you can achieve nearly the same safety without
>> putting any data on the chain.  All you need is a widely used
>> decentralized protocol that allows anyone who can prove ownership of a
>> UTXO to store some data.
>>
>
> I appreciate the suggestion, but I am really looking for a bitcoin-native
> solution to leverage bitcoin's robustness and security properties.
>
> By comparison, rolling
>> out relay of the annex and witness replacement may take months of review
>> and years for >90% deployment among nodes, would allow an attacker to
>> lower the feerate of coinjoin-style transactions by up to 4.99%, would
>> allow an attacker to waste 8 million bytes of bandwidth per relay node
>> for the same cost they'd have to pay to today to waste 400 thousand
>> bytes, and might limit the flexibility and efficiency of future
>> consensus changes that want to use the annex.
>
>
> That years-long timeline that you sketch for witness replacement (or any
> other policy change I presume?) to become effective is perhaps indicative
> of the need to have an alternative way to relay transactions to miners
> besides the p2p network?
>
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
>
> Joost
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>&gt; However, the primary adv=
antage I see in the annex is that its data isn&#39;t included in the calcul=
ation of the txid or a potential parent commit transaction&#39;s txid (for =
inscriptions). I&#39;ve explained this at [1]. This</div><div>&gt; feature =
makes the annex a powerful tool for applications that would ideally use cov=
enants.<br></div><div><br></div><div>I share the observation that the annex=
 data not being committed in the parent txid is very powerful for use-cases=
 that would use covenants. E.g there could be an alternative design of Coin=
Pool based on Grafroot, where the signed surrogate scripts authorized withd=
rawal abilities [0]. Once consumed the signed surrogate shouldn&#39;t be re=
playable against the clawback pool output, and the signature of the surroga=
te added as &quot;toxic&quot; in a cryptographic accumulator. Efficient set=
 test membership can be realized to refuse pool output spend attempts with =
consumed surrogate scripts.</div><div><br></div><div>The annex is a perfect=
 emplacement to locate such an accumulator in the future as the state of th=
e accumulator cannot be predicted as pool setup time and is a function of t=
he effective order withdrawal.</div><div><br></div><div>Note with Taproot-b=
ased design, the replay protection is achieved by the removal from the tapr=
oot tree as edited by any contracting primitive during the withdrawal phase=
 (e.g TLUV).</div><div><br></div><div>&gt; When it comes to the trade-offs =
associated with various encodings, I fully acknowledge their existence.=C2=
=A0The primary motivation behind my proposal to adopt a simple approach to =
the Taproot annex is to</div><div>&gt; avoid a potentially long standardiza=
tion process. While I am not entirely familiar with the decision-making pro=
cess of Bitcoin Core, my experience with other projects suggests that simpl=
er changes often</div><div>&gt; encounter less resistance and can be implem=
ented more swiftly. Perhaps I am being overly cautious here, though.<br></d=
iv><div><br></div><div>I fully understand the motivation to avoid a lengthy=
 standardization process, which can be a source of frustration for everyone=
, including the standard champions themselves. Indeed, no one lacks the bur=
eaucratic-style of standardization process for their own sake.</div><div><b=
r></div><div>Long standardization processes in Bitcoin consensus are better=
 explained by the number of technical dimensions to weigh in terms of desig=
ns (e.g full-nodes ressources scalability, fee economic costs, confidential=
ity, composability with other changes). And due to the asynchronous nature =
of FOSS development, every domain expert is constantly jungling between dif=
ferent engineering contributions priorities (e.g for myself currently packa=
ge relay and mempool for L2s).</div><div><br></div><div>All that said, to m=
ake the conversation of annex standardization more practical, and aiming to=
 compose with all technical interest expressed, I can think about a 2 phase=
 process, at least.</div><div><br></div><div>Such standardization process r=
eflects only my opinion, and is based on the experience of recent mempool f=
ullrbf partial deployment experience, the Core&#39;s trends to have trackin=
g issues for substantial changes, bitcoin-inquisition and the bitcoin contr=
acting primitives WG experiences.</div><div><br></div><div>Phase 1:</div><d=
iv>- a BIP proposal for the TLV records=C2=A0+ code (almost done with #9 in=
 bitcoin-inquisition and #1421 in the bips repository)</div><div>- a BIP pr=
oposal to reserve &quot;tag 0&quot; for unstructured data=C2=A0+ code (let&=
#39;s say in bitcoin-inquisition)</div><div>- anti-DoS mempool/transaction-=
relay/replacement code (same)</div><div>- bonus point: documenting the new =
mempool/replacement rules like in Core&#39;s `doc/policy`</div><div>- prefe=
rential peering logic working code (there is already some code with Core=
9;s #25600)</div><div>- opt-in activation of the annex validation rules</di=
v><div>- engage Bitcoin devs appreciated by the community as domain experts=
 in the covered areas to collect more relevant technical feedbacks</div><di=
v><br></div><div>Phase 2:</div><div>- submit the annex branch with all the =
features on the Bitcoin Core repository</div><div>- communicate to the Bitc=
oin technical community at large the existence of the proposal e.g dev mail=
 list, technical newsletters</div><div>- communicate to the second-layers a=
nd unstructured data application maintainers the existence of the proposal<=
/div><div>- integrate the feedback from Bitcoin Core, Bitcoin users and sec=
ond-layers communities in a &quot;staging code branch&quot;</div><div>- if =
there is a deep technical objection, go back to phase 1 (e.g a competing se=
rializing proposal for the annex)</div><div>- otherwise, split the annex re=
ference branch core in logical chunks for optimal review process</div><div>=
<br></div><div>This is what an efficient-yet-decentralized standardization =
process of the annex would look like to me, I don&#39;t know. About when we=
 can expect a deployment of new policy rules for the annex, as Dave made me=
 the (grounded) reprimand on the list a while back, I don&#39;t think menti=
oning a date or software version release is appropriate. And this to avoid =
creating a sense of commitment on all the contributors involved in the proj=
ects above mentioned.</div><div><br></div><div>I&#39;m still interested in =
championing the &quot;base&quot; TLV serialization annex code and BIP. To m=
ove faster, I think it would be better to have another champion on the &quo=
t;tag 0&quot; and BIP, especially as the unstructured data use-cases are co=
ming with their own specifics.</div><div><br></div><div>&gt; Regarding the =
potential payload extension attack, I believe that the changes proposed in =
the [3] to allow tx replacement by smaller witnesses would provide a viable=
 solution?=C2=A0<br><br class=3D"gmail-Apple-interchange-newline"></div><di=
v>To be honest, in terms of DoS, I wouldn&#39;t give a strong opinion befor=
e better formalization or consensus of the use-case requirements. From expe=
rience of Core&#39;s mempools PRs, you have few subcomponents that can be i=
nvolved (replacement, block template, broadcast backend of L2s, etc).</div>=
<div><br></div><div>&gt; That years-long timeline that you sketch for witne=
ss replacement (or any other policy change I presume?) to become effective =
is perhaps indicative of the need to have an alternative way to relay</div>=
<div>&gt; transactions to miners besides the p2p network?<br></div><div><br=
></div><div>Assuming an alternative p2p network, I don&#39;t think we can a=
void some standardization of fundamental data structures between those p2p =
network. Most of L2s are pre-signing transactions/packages and might not be=
 able to alter the validity of such set of transactions in a unilateral fas=
hion without re-introducing some =E2=80=9Cbad=E2=80=9D malleability. And a =
L2 node has an interest to use multiple p2p networks to mitigate against th=
ings like time-dilation attacks.</div><div><br></div><div>Best,</div><div>A=
ntoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2018-February/015700.html">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</a></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>Le=C2=A0dim. 11 juin 2023 =C3=A0=C2=A020:26, Joost Jager &lt;<a href=3D"ma=
ilto:joost.jager@gmail.com">joost.jager@gmail.com</a>&gt; a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Dave,</div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 11=
, 2023 at 12:10=E2=80=AFAM David A. Harding &lt;<a href=3D"mailto:dave@dtrt=
.org" target=3D"_blank">dave@dtrt.org</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
3. When paying the script in #2, Alice chooses the scriptpath spend from<br=
>
=C2=A0 =C2=A0 #1 and pushes a serialized partial signature for the ephemera=
l key<br>
=C2=A0 =C2=A0 from #2 onto the stack, where it&#39;s immediately dropped by=
 the<br>
=C2=A0 =C2=A0 interpreter (but is permanently stored on the block chain).=
=C2=A0 She also<br>
=C2=A0 =C2=A0 attaches a regular signature for the OP_CHECKSIG opcode.<br><=
/blockquote><div><br></div><div>Isn&#39;t it the case that that op-dropped =
partial signature for the ephemeral key isn&#39;t committed to and thus can=
 be modified by anyone before it is mined, effectively deleting the keys to=
 the vault? If not, this would be a great alternative!</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
Even better, I think you can achieve nearly the same safety without<br>
putting any data on the chain.=C2=A0 All you need is a widely used<br>
decentralized protocol that allows anyone who can prove ownership of a<br>
UTXO to store some data.=C2=A0=C2=A0<br></blockquote><div><br></div><div>I =
appreciate the suggestion, but I am really looking for a bitcoin-native sol=
ution to leverage bitcoin&#39;s robustness and security properties.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">By comparison, rolling<br>
out relay of the annex and witness replacement may take months of review<br=
>
and years for &gt;90% deployment among nodes, would allow an attacker to<br=
>
lower the feerate of coinjoin-style transactions by up to 4.99%, would<br>
allow an attacker to waste 8 million bytes of bandwidth per relay node<br>
for the same cost they&#39;d have to pay to today to waste 400 thousand<br>
bytes, and might limit the flexibility and efficiency of future<br>
consensus changes that want to use the annex.</blockquote><div><br></div><d=
iv>That years-long timeline that you sketch for witness replacement (or any=
 other policy change I presume?) to become effective is perhaps indicative =
of the need to have an alternative way to relay transactions to miners besi=
des the p2p network?</div><div><br></div><div>I agree though that it would =
be ideal if there is a good solution that doesn&#39;t require any protocol =
changes or upgrade path.</div><div><br></div><div>Joost</div></div></div>
</blockquote></div>

--0000000000009c975405fde6267a--