On Mon, Nov 07, 2022 at 04:21:11PM -0500, Suhas Daftuar via bitcoin-dev wrote:
> Hello bitcoin-dev,
> 
> The description in the OP is completely broken for the simple reason that
> Bitcoin transactions can have multiple inputs, and so a single transaction
> can conflict with multiple in-mempool transactions. The proposal would
> limit the number of descendants of each in-mempool transaction to
> MAX_REPLACEMENT_CANDIDATES (note that this is duplicative of the existing
> Bitcoin Core descendant limits), but a transaction that has, say, 500
> inputs might arrive and conflict with 500 unrelated in-mempool
> transactions. This could result in 12,500 evictions -- far more than the
> 100 that was intended.

That's easy to fix: just sum up the number of nReplacementCandidates for each
input in the multiple input case. Again, it'll overcount in the diamond case.
But so does the existing code.

The goal is to defeat pinning by ensuring that you can always replace a
transaction by double-spending an output; not that any possible way of
double-spending multiple outputs at once would work.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org