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.ja...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
