Standardisation of an unstructured taproot annex



Summary:

The issue at hand is related to annex malleability vector which could deceive developers into thinking their transactions are safe from replacement, when in reality they may not be. The problem arises when a transaction is denied entry into the mempool because someone submitted a strictly worse transaction for miners with no gain, by bloating its weight instead of adding fees. An example scenario would be a transaction with inputs A' and B' signed by two parties A and B, where A has a fully signed transaction in hand but cannot publish it due to B creating and publishing an alternative version of it with a large annex for input B'. In this case, it is assumed that the user has a direct connection to a miner, ignoring any potential concerns related to p2p transport. It is important to find reasonable methods for mitigating this issue.


Updated on: 2023-06-16T18:44:33.204008+00:00