📅 Original date posted:2023-06-03
🗒️ Summary of this message: The annex malleability vector could mislead developers into believing their transactions are immune to replacement, resulting in compromised assumptions.
📝 Original message:On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev 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. 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?
In the specific case of annex replacement leading to larger transactions, in
almost all cases you only care about the annex malleability causing the
transaction to take longer to get mined, due to it being larger. The fact the
transaction has become larger does not matter if the transaction does in fact
get mined, eg due to an out-of-band payment by the "attacker".
The only exception is the rare cases where some transaction processing
software/hardware has actual limits on transaction size. Eg you could imagine a
hardware wallet that simply *can't* process a transaction larger than a certain
size due to a lack of RAM.
I don't think this is a good rational to make use of the annex standard. Quite
the contrary: we should be thinking about if and how to fix annex malleability
in a future soft fork.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/b7420b57/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:22:08
in reply to nevent1q…yk2p
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:22:08Event JSON
{
"id": "6ff46d931994eba0ffe0fb63e47a76da899c48bfb3182a9dfadc61966fd9f05e",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686180128,
"kind": 1,
"tags": [
[
"e",
"b686717ee8b6c1778c5cebee48da470faaa2069000c176619f95f986554460f4",
"",
"root"
],
[
"e",
"3809e2a7cd6f9188a5f3c2c74203fa4c4e9cf2d0ab2b80d6a2072ce2983d98ea",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2023-06-03\n🗒️ Summary of this message: The annex malleability vector could mislead developers into believing their transactions are immune to replacement, resulting in compromised assumptions.\n📝 Original message:On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote:\n\u003e Depending on policy to mitigate this annex malleability vector could\n\u003e mislead developers into believing their transactions are immune to\n\u003e replacement, when in fact they might not be. This potential misalignment\n\u003e could result in developers and businesses constructing systems based on\n\u003e assumptions that could be compromised in the future, mirroring the\n\u003e situation that unfolded with zero-confirmation payments and rbf.\n\u003e \n\u003e It may thus be more prudent to permit the utilization of the annex without\n\u003e restrictions, inform developers of its inherent risks, and acknowledge that\n\u003e Bitcoin, in its present state, might not be ideally suited for certain\n\u003e types of applications?\n\nIn the specific case of annex replacement leading to larger transactions, in\nalmost all cases you only care about the annex malleability causing the\ntransaction to take longer to get mined, due to it being larger. The fact the\ntransaction has become larger does not matter if the transaction does in fact\nget mined, eg due to an out-of-band payment by the \"attacker\".\n\nThe only exception is the rare cases where some transaction processing\nsoftware/hardware has actual limits on transaction size. Eg you could imagine a\nhardware wallet that simply *can't* process a transaction larger than a certain\nsize due to a lack of RAM.\n\nI don't think this is a good rational to make use of the annex standard. Quite\nthe contrary: we should be thinking about if and how to fix annex malleability\nin a future soft fork.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/b7420b57/attachment.sig\u003e",
"sig": "f08e3d9ec91af6c841097b3282447592c49f0bc3d16c88303f58053c3c96cbb7c35294b3a128946f233293733ad1eecfc7e0c9c6c88eba523e4e6d1bd7700a18"
}