MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
In-Reply-To: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 11:14:27 +0200
Message-ID: <CAJBJmV8Vt_LLH-AEo-fCCs+S6uSy9UwC6QBakWY5tzn9Utwb8w@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d0149e05fd361aa3"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

HI Greg,

On Sat, Jun 3, 2023 at 3:14=E2=80=AFAM Greg Sanders <gsanders87@gmail.com> =
wrote:

> Attempting to summarize the linked PR:
>
> I think the biggest remaining issue to this kind of idea, which is why I
> didn't propose it for mainnet,
> is the fact that BIP341/342 signature hashes do not cover *other* inputs'
> annex fields, which we
> briefly discussed here
> https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r114338=
2264
> .
>
> This means that in a coinjoin like scenario, even if the other joining
> parties prove they don't have any
> crazy script paths, a malicious party can make the signed transaction int=
o
> a maximum sized transaction
> package, causing griefing. The mitigation in the PR I linked was to limit
> it to 126 bytes, basically punting
> on the problem by making the grief vector small. Another solution could b=
e
> to make annex usage "opt-in"
> by requiring all inputs to commit to an annex to be relay-standard. In
> this case, you've opted into a possible
> vector, but at least current usage patterns wouldn't be unduly affected.
> For those who opt-in, perhaps the first
> order of business would be to have a field that limits the total
> transaction weight, by policy only?
>
> Some logs related to that here:
> https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb
>
> Related discussion on possible BIP118 modifications to mitigate this in
> tapscript-spending circumstances:
> https://github.com/bitcoin-inquisition/bitcoin/issues/19
>

While solutions such as making annex usage opt-in or imposing size
limitations may initially appear effective, they may also inadvertently
foster a false sense of security, as they lack alignment with economic
incentives.

Relying solely on policy enforcement merely transfers responsibility to the
miners, without necessarily aligning their incentives with the broader
network health. This situation is reminiscent of the challenges encountered
with opt-in rbf. Despite signaling for non-replaceability, miners began
accepting replacements probably due to the enticing higher fee incentives.
At least that's how I picked up this development. Businesses that relied on
zero-confirmation payments were unexpectedly affected, leading to
undesirable outcomes.

While we can define policy rules, miners will ultimately operate in a
manner that maximizes their profits. Consequently, if a miner identifies an
opportunity to bolster their fees by replacing an annex transaction,
they're likely to seize it, regardless of any policy rules. This might not
be readily apparent currently with a limited number of pools dominating
block production, but it is my hope that mining will be more decentralized
in the future.

Depending on policy to mitigate this annex malleability vector could
mislead developers into believing their transactions are immune to
replacement, when in fact they might not be. This potential misalignment
could result in developers and businesses constructing systems based on
assumptions that could be compromised in the future, mirroring the
situation that unfolded with zero-confirmation payments and rbf.

It may thus be more prudent to permit the utilization of the annex without
restrictions, inform developers of its inherent risks, and acknowledge that
Bitcoin, in its present state, might not be ideally suited for certain
types of applications?

Joost

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

<div dir=3D"ltr"><div dir=3D"ltr">HI Greg,<div><br></div></div><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 3, 2023 =
at 3:14=E2=80=AFAM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com"=
>gsanders87@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div id=3D"m_-811107207189304988gmail-:3h=
l" aria-label=3D"Message Body" role=3D"textbox" aria-multiline=3D"true" sty=
le=3D"direction:ltr;min-height:85px" aria-controls=3D":3k2"><div>Attempting=
 to summarize the linked PR:</div><div><br></div><div>I think the biggest r=
emaining issue to this kind of idea, which is why I didn&#39;t propose it f=
or mainnet,</div><div>is the fact that BIP341/342 signature hashes do not c=
over *other* inputs&#39; annex fields, which we</div><div>briefly discussed=
 here=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/2=
2#discussion_r1143382264" target=3D"_blank">https://github.com/bitcoin-inqu=
isition/bitcoin/pull/22#discussion_r1143382264</a> .=C2=A0</div><div><br></=
div><div>This means that in a coinjoin like scenario, even if the other joi=
ning parties prove they don&#39;t have any</div><div>crazy script paths, a =
malicious party can make the signed transaction into a maximum sized transa=
ction</div><div>package, causing griefing. The mitigation in the PR I linke=
d was to limit it to 126 bytes, basically punting</div><div>on the problem =
by making the grief vector small. Another solution could be to make annex u=
sage &quot;opt-in&quot;</div><div>by requiring all inputs to commit to an a=
nnex to be relay-standard. In this case, you&#39;ve opted into a possible</=
div><div>vector, but at least current usage patterns wouldn&#39;t be unduly=
 affected. For those who opt-in, perhaps the first</div><div>order of busin=
ess would be to have a field that limits the total transaction weight, by p=
olicy only?</div><div><br></div><div>Some logs related to that here:=C2=A0<=
a href=3D"https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7=
bb" target=3D"_blank">https://gist.github.com/instagibbs/7406931d953fd96fea=
28f85be50fc7bb</a></div><div><br></div><div>Related discussion on possible =
BIP118 modifications to mitigate this in tapscript-spending circumstances:=
=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/issues/19" =
target=3D"_blank">https://github.com/bitcoin-inquisition/bitcoin/issues/19<=
/a></div></div></div></blockquote><div><br></div>While solutions such as ma=
king annex usage opt-in or imposing size limitations may initially appear e=
ffective, they may also inadvertently foster a false sense of security, as =
they lack alignment with economic incentives.<br><br>Relying solely on poli=
cy enforcement merely transfers responsibility to the miners, without neces=
sarily aligning their incentives with the broader network health. This situ=
ation is reminiscent of the challenges encountered with opt-in rbf. Despite=
 signaling for non-replaceability, miners began accepting replacements prob=
ably due to the enticing higher fee incentives. At least that&#39;s how I p=
icked up this development. Businesses that relied on zero-confirmation paym=
ents were unexpectedly affected, leading to undesirable outcomes.<br><br>Wh=
ile we can define policy rules, miners will ultimately operate in a manner =
that maximizes their profits. Consequently, if a miner identifies an opport=
unity to bolster their fees by replacing an annex transaction, they&#39;re =
likely to seize it, regardless of any policy rules. This might not be readi=
ly apparent currently with a limited number of pools dominating block produ=
ction, but it is my hope that mining will be more decentralized in the futu=
re.<br><br>Depending on policy to mitigate this annex malleability vector c=
ould mislead developers into believing their transactions are immune to rep=
lacement, when in fact they might not be. This potential misalignment could=
 result in developers and businesses constructing systems based on assumpti=
ons that could be compromised in the future, mirroring the situation that u=
nfolded with zero-confirmation payments and rbf.<br><br><div>It may thus be=
 more prudent to permit the utilization of the annex without restrictions, =
inform developers of its inherent risks, and acknowledge that Bitcoin, in i=
ts present state, might not be ideally suited for certain types of applicat=
ions?</div><div><br></div><div>Joost=C2=A0</div></div></div>

--000000000000d0149e05fd361aa3--