Skip to content

Instantly share code, notes, and snippets.

@instagibbs

instagibbs/ln-symmetry.md

Last active January 5, 2024 17:12
Show Gist options
  • Save instagibbs/7a237783f2532f5bfdb29dc7cd80dca2 to your computer and use it in GitHub Desktop.
Save instagibbs/7a237783f2532f5bfdb29dc7cd80dca2 to your computer and use it in GitHub Desktop.
Download ZIP
ln-symmetry Project
Raw
ln-symmetry.md

LN-Symmetry Project

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:

  1. channel opens
  2. payments (revamped + simplified channel state machine)
  3. payments with hops
  4. unilateral closes

It did not implement:

  1. 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
  2. Proper persistence of the new keytypes/fields. In other words, if you restart your node, you'll crash. Couldn't quite figure it out
  3. anchor spending support: Rusty was working hard at the time on option_anchors support; rebasing everything on top now should fix this
  4. 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:

Key Focuses

  1. 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.
  2. 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?

Key Takeaways

  1. 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.
  2. eltoo-style channels have even longer than expect htlc expiry deltas to stay secure. No one had actually worked through the state machine before.
  3. 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.
  4. 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.
  5. 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.

Key work artifacts

  1. 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.
  2. CLN implementation here: https://github.com/instagibbs/lightning/tree/eltoo_support
  3. 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)
  4. or maybe https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v25.1-inq
  5. BOLT draft for ln-symmetry(with segwit ephemeral anchors): https://github.com/instagibbs/bolts/tree/eltoo_draft
  6. libwally work to support taprooty CLN changes(chunks of this was upstreamed but not all): https://github.com/instagibbs/libwally-core/tree/taproot
  7. 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
  8. Backporting anti-pin tech to today's BOLTs with proposed Bitcoin Core policy changes only: https://github.com/instagibbs/bolts/commits/zero_fee_commitment

Current Status

On hold. I hope this work helps derisk conversations about future softforks and channel designs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment