Lightning transactions with v3 and ephemeral anchors

[instagibbs]

Sibling Eviction for v3 transactions

When we receive a transaction that would bust a mempool transaction’s descendant limits, we usually reject it (unless it is eligible for CPFP carve out). An alternative approach (e.g. when this transaction is very high feerate and it’d be a shame to let it go) is to consider evicting the least incentive compatible descendant in favor of this new transaction. That way we don’t compromise on our anti-DoS-motivated descendant limit (like we do with CPFP carve out), but don’t need to be stuck with …

this topic is relevant to discussion.

If we do sibling eviction more generally in v3:

1. “imbued” commitment transactions prior to any spec update would be RBF’ing other anchor spends, rather than using a carveout
2. you could go with a 330 sat (shared)keyed anchor, and still remove 1 CSV from all other scripts. Or have N anchors

in other words, ephemeral anchors would be about make anchors cheaper and potential separation of funds/fees, rather than the side benefit of sibling eviction.

You could also drop the ephemeral/keyed anchor in a commit tx in certain cases, like a commit tx with only the remote balance output left, and probably other cases.