MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAJBJmV9JYYOSJXbzhrGTrv3jf_qGoLRbq9COgbBmuinpNAOhDg@mail.gmail.com>
 <CAJBJmV_UR9ND2vK1+BVeKQ==xdsamJ_7U-X4LH67J9g57UrkTw@mail.gmail.com>
 <CAB3F3Dugso9MUqr5hMMorL7FargPPspiof+0-qkYGnP_SLyELg@mail.gmail.com>
 <CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
In-Reply-To: <CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sat, 3 Jun 2023 08:43:38 -0400
Message-ID: <CAB3F3Dvm1KAHN2OoA_av2WE1=WZ0hNU6paAtN6c9L6+QFw6pfw@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000049584c05fd390550"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

--00000000000049584c05fd390550
Content-Type: text/plain; charset="UTF-8"

No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.

Cheers,
Greg

On Sat, Jun 3, 2023, 8:36 AM Joost Jager <joost.jager@gmail.com> wrote:

> > 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.
>>
>> The issue I'm talking about is where someone's transaction is denied
>> entry into the mempool entirely because a counter-party decided to put in a
>> strictly worse transaction for miners by bloating the weight of it, not
>> adding fees. A strictly worse "API" for paying miners for no gain seems
>> like a bad trade to me, especially when there are reasonable methods for
>> mitigating this.
>>
>
> Just to expand this, an example would be a transaction with inputs A' and
> B' signed by two parties A and B. A has a fully signed transaction in
> hands, but can't publish it because B created and published an alternative
> version of it with a large annex for input B'. Wouldn't miners just accept
> A's version because it's fee rate is higher? I am looking at this case
> assuming the user has a direct connection to a miner, ignoring any
> potential concerns related to p2p transport.
>
> Joost
>

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

<div dir=3D"auto">No in this case the txid is identical. Only the wtxid is =
malleated, with annex data stuffed to max transaction size.=C2=A0<div dir=
=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto">Greg</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sat, Jun 3, 2023, 8:36 AM Joost Jager &lt;<a href=3D"mailto:joost.ja=
ger@gmail.com">joost.jager@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>&gt; 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.=C2=A0<br></div><div><br></div><div>The issue I&#39;m tal=
king about=C2=A0is where someone&#39;s transaction is denied entry into the=
 mempool entirely because a counter-party decided to put in a strictly wors=
e transaction for miners by bloating the weight of it, not adding fees. A s=
trictly worse &quot;API&quot; for paying miners for no gain seems like a ba=
d trade to me,=C2=A0especially when there are reasonable methods for mitiga=
ting this.</div></div></blockquote><div><br></div><div>Just to expand this,=
 an example would be a transaction with inputs A&#39; and B&#39; signed by =
two parties A and B. A has a fully signed transaction in hands, but can&#39=
;t publish it because B created and published an alternative version of it =
with a large annex for input B&#39;. Wouldn&#39;t miners just accept A&#39;=
s version because it&#39;s fee rate is higher? I am looking at this case as=
suming the user has a direct connection to a miner, ignoring any potential =
concerns related to p2p transport.</div><div><br></div><div>Joost</div></di=
v></div>
</blockquote></div>

--00000000000049584c05fd390550--