📅 Original date posted:2023-06-03
🗒️ Summary of this message: The issue of annex malleability in Bitcoin transactions could mislead developers into thinking their transactions are immune to replacement, warns a developer. The problem arises when a transaction is denied entry into the mempool because a counter-party has put in a strictly worse transaction for miners by bloating its weight, not adding fees.
📝 Original message:
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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/49e83857/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-19 20:19:53
in reply to nevent1q…shdc
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-19 20:19:53Event JSON
{
"id": "fe8bfbc0c7a33443a8638205187fe56dbbc99b385a600ad45cb788338374e938",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1687198793,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"41fa9006918b5cbd70f00bc699d0ef6240b0cd57e9b3574c0fe02ab9f6d1f326",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2023-06-03\n🗒️ Summary of this message: The issue of annex malleability in Bitcoin transactions could mislead developers into thinking their transactions are immune to replacement, warns a developer. The problem arises when a transaction is denied entry into the mempool because a counter-party has put in a strictly worse transaction for miners by bloating its weight, not adding fees.\n📝 Original message:\nNo in this case the txid is identical. Only the wtxid is malleated, with\nannex data stuffed to max transaction size.\n\nCheers,\nGreg\n\nOn Sat, Jun 3, 2023, 8:36 AM Joost Jager \u003cjoost.jager at gmail.com\u003e wrote:\n\n\u003e \u003e Depending on policy to mitigate this annex malleability vector could\n\u003e\u003e mislead developers into believing their transactions are immune to\n\u003e\u003e replacement, when in fact they might not be.\n\u003e\u003e\n\u003e\u003e The issue I'm talking about is where someone's transaction is denied\n\u003e\u003e entry into the mempool entirely because a counter-party decided to put in a\n\u003e\u003e strictly worse transaction for miners by bloating the weight of it, not\n\u003e\u003e adding fees. A strictly worse \"API\" for paying miners for no gain seems\n\u003e\u003e like a bad trade to me, especially when there are reasonable methods for\n\u003e\u003e mitigating this.\n\u003e\u003e\n\u003e\n\u003e Just to expand this, an example would be a transaction with inputs A' and\n\u003e B' signed by two parties A and B. A has a fully signed transaction in\n\u003e hands, but can't publish it because B created and published an alternative\n\u003e version of it with a large annex for input B'. Wouldn't miners just accept\n\u003e A's version because it's fee rate is higher? I am looking at this case\n\u003e assuming the user has a direct connection to a miner, ignoring any\n\u003e potential concerns related to p2p transport.\n\u003e\n\u003e Joost\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/49e83857/attachment.html\u003e",
"sig": "e0f1944f64853bb31ef2a134d9aceb8f99fb0e3813176d9f0aec47a56ac2344a5124a9cd66f5005750ed1ad9071ae652ca2f950c23ec8d5aee88888557886e94"
}