📅 Original date posted:2023-06-03 🗒️ Summary of this message: A policy to ...

Joost Jager [ARCHIVE] /

npub1asl…fqmx

2023-06-07 23:22:09

in reply to nevent1q…4kp8

📅 Original date posted:2023-06-03
🗒️ Summary of this message: A policy to mitigate annex malleability could mislead developers into thinking their transactions are immune to replacement, when they may not be.
📝 Original message:>
> > 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/08c8c4df/attachment-0001.html>;

Author Public Key

npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx

Seen on

wss://relay.noswhere.com

Show more details

Published at

2023-06-07 23:22:09

Kind type

1 Short Text Note

Event JSON

{ "id": "50536513d55667c5fc411095de8997f85ff366215d72b1d06ff1595f63c8c397", "pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3", "created_at": 1686180129, "kind": 1, "tags": [ [ "e", "b686717ee8b6c1778c5cebee48da470faaa2069000c176619f95f986554460f4", "", "root" ], [ "e", "23624fc1f5fef9bc1564242dbd674a46bce1fd01efeeb63ebc8c45e81fa21c36", "", "reply" ], [ "p", "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19" ] ], "content": "📅 Original date posted:2023-06-03\n🗒️ Summary of this message: A policy to mitigate annex malleability could mislead developers into thinking their transactions are immune to replacement, when they may not be.\n📝 Original message:\u003e\n\u003e \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.\n\u003e\n\u003e The issue I'm talking about is where someone's transaction is denied entry\n\u003e into the mempool entirely because a counter-party decided to put in a\n\u003e strictly worse transaction for miners by bloating the weight of it, not\n\u003e adding fees. A strictly worse \"API\" for paying miners for no gain seems\n\u003e like a bad trade to me, especially when there are reasonable methods for\n\u003e mitigating this.\n\u003e\n\nJust to expand this, an example would be a transaction with inputs A' and\nB' signed by two parties A and B. A has a fully signed transaction in\nhands, but can't publish it because B created and published an alternative\nversion of it with a large annex for input B'. Wouldn't miners just accept\nA's version because it's fee rate is higher? I am looking at this case\nassuming the user has a direct connection to a miner, ignoring any\npotential concerns related to p2p transport.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/08c8c4df/attachment-0001.html\u003e", "sig": "c1a936e94326a9e209f9759acce3a9b8d1e3310d1c452535c0d75ec93ab89d0ca993dbe8f093bcf7abb8ed37a761e99177ec0cf2da944adcc62a4d3c83612273" }