[mempool] A single standard sized transaction should not preclude a CPFP #15046

1. 
   instagibbs commented at 8:47 pm on December 27, 2018: member

   Current relay policy can lead to a situation where an unconfirmed payment output can be swept by the payee with a standard ~100kvB transaction, such that the payer cannot bump their own package feerate due to the descendant size limits.

   One naive way to shore this up would be to increase the total descendant size limit such that this cannot reasonably happen with a single transaction griefing the whole package limit, even if the payer is making small-ish packages.

2. fanquake added the label Mempool on Dec 27, 2018
3. 
   benthecarman commented at 12:33 pm on January 8, 2019: contributor

   A safer way to do it could be making it so the size limit can be broken by X% if a transaction fee is trying to be bumped. This would allow someone to still bump their fee, but not throw in another huge transaction on top of it.
4. 
   benthecarman commented at 11:27 pm on January 12, 2019: contributor

   Another way could be to limit the % a descendant can use the descendant size limit. For example, you could have 5 descendants using 20% of the size limit but not 1 using 100%
5. 
   MarcoFalke commented at 8:17 pm on August 1, 2019: member

   @instagibbs Is this still an issue after #15681?
6. 
   instagibbs commented at 8:20 pm on August 6, 2019: member

   That PR carves out a single (useful) exception, but in general relay can still be abused. e.g., if the tx you’re replacing has more than one ancestor(IIRC, I’d have to re-read the PR again)
7. 
   instagibbs commented at 2:08 pm on October 2, 2019: member

   So after more thinking and research, I believe #16421 and #15681 do indeed fix this issue.

   A single transaction off your transaction(or chain from one output) is unable to pin it any longer with the carve-out rule.

   This should be enough to make reliable(enough) CPFP/RBF more than a dream in production systems. An adversary could also take the carve-out rule slot in a batch withdrawal setting, but wags finger at customer let’s just assume most pinning is done on accident.

8. instagibbs closed this on Oct 2, 2019

   ---

9. MarcoFalke locked this on Dec 16, 2021

Contributors
instagibbs benthecarman MarcoFalke

Labels
Mempool