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