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>
In-Reply-To: <CAB3F3Dugso9MUqr5hMMorL7FargPPspiof+0-qkYGnP_SLyELg@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 14:35:51 +0200
Message-ID: <CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000cb2e505fd38eb5f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

--0000000000000cb2e505fd38eb5f
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" 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 mitiga=
te this annex malleability vector could mislead developers into believing t=
heir 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 talking about=C2=A0i=
s where someone&#39;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 &qu=
ot;API&quot; for paying miners for no gain seems like a bad trade to me,=C2=
=A0especially when there are reasonable methods for mitigating 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 bec=
ause B created and published an alternative version of it with a large anne=
x 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 assuming the user h=
as a direct connection to a miner, ignoring any potential concerns related =
to p2p transport.</div><div><br></div><div>Joost</div></div></div>

--0000000000000cb2e505fd38eb5f--