Published on: 2022-11-07T21:27:16+00:00
In a message posted on the Bitcoin-dev mailing list, Suhas Daftuar pointed out a flaw in the proposal to limit the number of descendants of each in-mempool transaction. The issue arises from the fact that a single transaction can conflict with multiple in-mempool transactions, as Bitcoin transactions can have multiple inputs. This could lead to more evictions than intended. Peter Todd suggested a solution by summing up the number of nReplacementCandidates for each input in the multiple input case. The objective is to ensure that a transaction can always be replaced by double-spending an output to defeat pinning, rather than making every possible way of double-spending multiple outputs work.To address the pinning problem caused by Rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced and evicted from the mempool, the Replaceability Invariant has been proposed. The goal of this proposal is to ensure that all transactions in the mempool are always replaceable, thereby eliminating the need for Rule #5. The Replaceability Invariant involves assigning an integer, nReplacementCandidates, to each transaction. When a non-conflicting transaction is accepted into the mempool, the nReplacementCandidates value is incremented by 1 for each unconfirmed parent. Conflicting transactions do not require verification as the invariant guarantees their replaceability. When a block is mined, the nReplacementCandidates of all unconfirmed transactions remains unchanged since a confirmed transaction cannot spend an unconfirmed txout. A special case is needed to handle reorgs that change a transaction from confirmed to unconfirmed, where setting nReplacementCandidates to MAX_REPLACEMENT_CANDIDATES would suffice. The proposal also acknowledges that accommodating diamond tx graphs is unnecessary as they are even more unusual than unconfirmed children.Currently, Bitcoin Core implements rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced in the mempool to a total of 100. However, this rule lacks justification beyond avoiding excessive computational work and may not be necessary considering the natural limits imposed by the overall mempool size. To avoid pinning caused by rule #5, the Replaceability Invariant can be implemented. This invariant ensures that no transaction is accepted into the mempool if it would prevent another transaction from being replaced due to Rule #5. Implementing the Replaceability Invariant is straightforward: for each transaction, maintain an integer called nReplacementCandidates. When evaluating a non-conflicting transaction for acceptance into the mempool, verify that nReplacementCandidates + 1 does not exceed the MAX_REPLACEMENT_CANDIDATES limit. If the limit is exceeded, reject the new transaction. By guaranteeing the replaceability of all transactions in the mempool, the problem of Rule #5 pinning can be resolved.
Updated on: 2023-08-02T08:26:05.083482+00:00