Noting up front that these scenarios are what I’m calling “cross-sponsor” RBF, where the funding tx is sponsoring on package, then switches over to sponsor another parent. Typical example for a wallet would be they’re CPFPing something with a nice sized utxo, then another package becomes higher priority and they want to switch.
I don’t think it should be shocking miner scores isn’t strictly improving the mempool. I’m also unconvinced it’s worth stalling out limited package rbf given the current state of the art, which is substantially worse.
At the risk of re-adding a pin, changing the heuristic to:
- for all direct conflicts, package feerate must exceed direct conflict’s feerate
- for all conflicts(direct or indirect), package feerate must exceed ancestor feerate of conflict
may be something to double-check.
This is what https://github.com/bitcoin/bitcoin/pull/25038 had essentially implemented, which means the specific cross-sponsor RBF becomes relatively impractical.
Example test case for this using this “old” heuristic:
Or C with B, I believe that’s equivalent in this case.
Gloria and I had this exact discussion prior: policy: nVersion=3 and Package RBF by glozow · Pull Request #25038 · bitcoin/bitcoin · GitHub
Wallet authors can avoid this in a fairly simple manner, by not “cross-sponsoring”. If they do, make it a 0-fee parent package via v3/ephemeral anchors, but note that if a counter-party has already sponsored the package, cross-sponsoring will still be disallowed since parent will still be in the mempool. Post-cluster mempool this issue goes away (except the mild pinning as you note in issue 3?)
Don’t have anything intelligible to say about issue 3 yet other than it’s interesting!