ln-symmetry started with a simple idea: Someone should take the eltoo idea and take it as far as possible to prove out the concept, without requiring community consensus required actions like softforks before proving it out.
The end result is research-level quality software, with basic functional tests of the common cases:
- channel opens
- payments (revamped + simplified channel state machine)
- payments with hops
- unilateral closes
It did not implement:
- cooperative closes: There's a lot of spec work to make this better for today's channels, and it would nearly be copy-paste, so I didn't bother
- Proper persistence of the new keytypes/fields. In other words, if you restart your node, you'll crash. Couldn't quite figure it out
- anchor spending support: Rusty was working hard at the time on
option_anchorssupport; rebasing everything on top now should fix this - Gossip for these channels. So if you're playing around with it, you need to use them as private channels
I also got these opens/closes broadcasted on signet via bitcoin-inquisition:
- KISS: I felt almost too stupid to understand the current BOLTs. How much shorter and simpler can I make them with a new channel type using APO-like functionality? Answer is quite a bit, at least within BOLTs 2, 3, and 5.
- De-risking eltoo technical challenges: What are we missing in our handwaves of an idea? There's always something. Is that something fatal to the idea?
- Pinning is super hard to avoid. At least 1/3 of the work I bet was designing the system to be as robust against pinning as possible. I think I completed the task, except for HTLC-Success cases which actually need to be pre-signed to be pin-resistant. It's my biggest remaining design bug I know about.
- eltoo-style channels have even longer than expect htlc expiry deltas to stay secure. No one had actually worked through the state machine before.
- Much more flexible fee management: All outputs in settlement transactions(except HTLC-Success paths as noted before) are free to spend, allowing endogenous fees from all other output cases of balance and HTLC outputs. Reduces the burden on having a utxo pool for fees to only pay maximum once per unilteral close during the "challenge" period.
- CTV(emulation) ended up being useful! It removed the necessity of round-trips from the payment protocol, allowing for "fast forwards" that are extremely simple, and would likely reduce payment times if widely adopted.
- I'm less convinced than ever that penalties are the way forward in the future. Penalties are, in practice against a competent adversary, only as large as their reserve requirements, so "make sure it works right" seems to be the best deterrent. Make the expected chance of success essentially zero, and the incentive should be to collaboratively close to save fees.
- Tons of anti-pinning research resulting in many milestones in the Package Relay Project including my novel invention of Ephemeral Anchors which builds on top of "V3" concept.
- CLN implementation here: https://github.com/instagibbs/lightning/tree/eltoo_support
- Bitcoin Core branch with necessary changes for CLN blackbox tests: https://github.com/instagibbs/bitcoin/tree/202207-anyprevout (though this has non-segwit version of ephemeral anchors)
- or maybe https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v25.1-inq
- BOLT draft for ln-symmetry(with segwit ephemeral anchors): https://github.com/instagibbs/bolts/tree/eltoo_draft
- libwally work to support taprooty CLN changes(chunks of this was upstreamed but not all): https://github.com/instagibbs/libwally-core/tree/taproot
- Notes on PTLCs, where eltoo-style channels get trivial fast-forwards still(aka APO-style fork fixes this): https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163#single-sig-adaptor-ln-symmetry
- Backporting anti-pin tech to today's BOLTs with proposed Bitcoin Core policy changes only: https://github.com/instagibbs/bolts/commits/zero_fee_commitment
On hold. I hope this work helps derisk conversations about future softforks and channel designs.