On mempool policy consistency



Summary:

In a discussion on the bitcoin-dev mailing list, AdamISZ/waxwing questioned whether it was necessary for B and C in a scenario described by Antoine Towns to not see A's opt-out "pre-replacement" transaction (TX_2). In the scenario, A, B, and C create a transaction with opt-in RBF, but before publishing it, A spams the network with an alternative transaction double-spending her input. This causes problems for B and C who have already populated their mempool with the first transaction. While they cannot replace the first transaction, they should at least be able to hear about the second one. The attack is not a big concern in Joinmarket, and the solution is just to have a 'taker in charge of network fee; if it's slow or gets double-spent out causing time delay then just wait', combined with 'there isn't any economic incentive for an attacker.' Off-chain contracting has more sophisticated considerations.


Updated on: 2023-06-16T02:25:56.693723+00:00