Lightning transactions with v3 and ephemeral anchors

Protocol Design
,
2

Note that this is easily done by having the feature not be option_anchors, since that’s the prior format for all the output scripts.

The other discussion that came up is that of deployment strategy. There’s a bit of a timeline problem:

  1. We need to roll out updates to mempool/relay to make the transition to v3 style transactions safe, so LN implementations can adopt it
  2. We need LN implementations to update before we can deploy cluster mempool upgrade, since CPFP carveout as it stands is inapplicable to cluster mempool.

A suggestion on the call was essentially “what if Bitcoin Core implicitly opts commitment transactions that rely on CPFP carveout into a new regime that doesn’t rely on the carveout per se”?

This could lead to a revised project roadmap:

  1. V3, 2-cluster package rbf, 1p1c relay + mild orphanage churn protection
  2. Imbue LN commit txs with two anchors with “implicit signaling” of V3
    a) Anything with two 330-sat outputs?
    i) Or get more specific, e.g., one input only, nversion==2, a couple of bytes here or there…
    b) Allow 1p2c “cpfp carveout”
    i) “One more” child, same size limitations as normal v3 child tx limit
    ii) This, along with 2-cluster package RBF, means if you stop spending the remote anchor, you can now efficiently do package rbf against remote tx, and the counter-party cannot pin local commit tx. Child will have to be “small” following V3 rules. Exact implementation TBD
  3. Further rollouts, with no inherent inter-dependencies a) Cluster mempool b) Further make orphan handling robust c) Ephemeral anchors d) LN spec update to do 0-fee commit txns
  4. … Remove the 1p2c CPFP carveout

It doesn’t interfere with the current work, and removes critical paths from deployment, so I think it’s worth considering.

With the revised timeline, we may be able to swap out CPFP carveout without doing any harm, allow implementations to improve their security via limited package rbf, and allow spec updates to happen on their own time for further improvements.

V3 Child tx size

We would also like feedback on what the maximal V3 child size should be. It’s an inherent tradeoff between practical CPFP tx sizes and potential pin vectors, so it’d be nice to know what expectations are around that from any wallet project.

1 Like