To clarify, this would be in addition to package RBF and 1p1c package relay.
Exactly. We’re “replacing” our sibling even though we don’t actually spend the same input / have a conflict with them.
Right, in v3, there’s only siblings (direct child of a direct parent). We’ve also talked about this for more complex topologies, where you can evict some descendant of your ancestor (I’m hesitant to use family relationship terms as it starts getting a bit Game of Thronesy…)
(I’ve edited the original post now to include a clearer definition, thanks).
Going back to the “imbuing existing LN commitment transactions with v3 while they aren’t actually v3” idea, we want to make it so that if your remote broadcasts one of the following:
- (1r) their commit + child of their anchor
- (2r) your commit + child of their anchor
You are always able to CPFP by broadcasting:
- (1l) your commit + child of your anchor
- (2l) child of their anchor
- subsequent child RBF if you want to raise the fee again
So regardless of what happens, you are always able to bump:
- (1l) can replace (1r) via package RBF
- (1l) can replace the (2r) child via sibling eviction
- (2l) can replace (1r) child via sibling eviction.
And mempools will keep the 1-parent-1-child topology instead of needing to deal with 2 children (breaks package RBF which currently is based on 1p1c).