Lightning Specification Meeting 2025/02/10

[t-bast]

The meeting will take place on Monday 2025/02/10 at 7pm UTC (5:30am Adelaide time) on Libera Chat IRC #lightning-dev. It is open to the public.

A video link is available for higher bandwidth communication: https://meet.jit.si/Lightning-Spec-Meeting

Recently Updated Proposals / Seeking Review

This section contains changes that have been opened or updated recently and need feedback from the meeting participants.

• Simplified mutual close option_simple_close (features 60/61) #1205
• Announcement confirmation follow-up More clarifications around channel_announcement handling #1220
• Dual funding reconnect commit_sig retransmission Do not unnecessarily retransmit commitment_signed in dual funding #1214
• splice_locked retransmission Improve splice_locked retransmission logic #1223
• 0-fee commitments anchor script: https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412
• ZKP Gossip: https://delvingbitcoin.org/t/zk-gossip-for-lightning-channel-announcements/1407/17
• Channel jamming draft: HTLC Endorsement to Mitigate Channel Jamming #1071 Project Updates: Hybrid Channel Jamming Mitigation #1218
• Splicing Channel Splicing (feature 62/63) #1160
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Dynamic Commitments Extension/dynamic commitments #1117
• Bolt 12 contacts: blip-0042: Bolt 12 Contacts blips#42
• Liquidity ads Extensible Liquidity Ads #1153
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Async payments Support async payments in BOLT 12 #1149

Stale Proposals

This section contains pending changes that may not need feedback from the meeting participants, unless someone explicitly asks for it during the meeting. These changes are usually waiting for implementation work to happen to drive more feedback.

• Inbound fees Inbound routing fees blips#18 and Add a bLIP for backwards-compatible inbound fees blips#22

Waiting for interop

This section contains changes that have been conceptually ACKed and are waiting for at least two implementations to fully interoperate.
They most likely don't need to be covered during the meeting, unless someone asks for updates.

• Zero reserve Add option_zero_reserve (FEATURE 64/65) #1140 (follow-up on bolt2: relax channel_reserve_satoshis requirements #1133 to include a feature bit)
• Attributable errors Attributable failures (feature 36/37) #1044
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• Simplified commitment Feature 106/107: option_simplified_update. #867
• lnprototest (/~https://github.com/rustyrussell/lnprototest)

[carlaKC]

Posted some jamming updates on delving (solidifying my title as dirtbag of the day by posting 10 minutes before the meeting), would like to chat about them!

[Roasbeef]

simple coop close:

• interop between lnd and eclair now!
• can merge after a final pass from relevant parties

HTLC pinning, PTLC, v3:

• in order to address all the gaps, we also need the remote party's HTLCs to all be pre-signed
  • points towards needing to go with simplified commitment, or some other variant
• fork in the road:
  • incrementally do v3, leaves some pinning gaps:
    • just the new commitment type
    • gives us zero fee commitments, gets around lots of UX warts
    • also resolves issues w/ reserve, etc
    • dust simplified, no floating dust limit
  • fix everything all at once: simplified commitment, new commitment flow
    • larger design space
    • also adds PTLCs
    • able to finally reject HTLCs up front
    • taproot in the critical path
• what should the new anchor type be?
  • https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412/14
    • do we want only the miners to be able to claim the dust HTLCs?
      • otherwise the peer can siphon off those HTLCs
        * taproot or not?
    • otherwise need 3 commitment types: anchor, v3+p2a, taproot
      • present issue now, so can bite the bullet and do it w/ and w/o taproot
      • commitment changes themselves are small

zkp channel proofs:

• very cool stuff: https://delvingbitcoin.org/t/zk-gossip-for-lightning-channel-announcements/1407/1
• main issue still with tooling:
  • everyone one need to integrate it into their codebase, pull in all the deps
  • tooling is more mature, but not sure ready for primetime yet
• if not p2p, can still go RPC route similar to RGS

channel jamming update:

• new poast: https://delvingbitcoin.org/t/hybrid-jamming-mitigation-results-and-updates/1147/7
• do we enforce reputation in both directions?

splicing:

• few final interop issues working through, once solved

taproot:

• lnd working on adding taproot support to rbf coop close

[Roasbeef]

stfu:

• what happens when you send stfu, but then they send a shutdown?
  • should be clarified
  • maybe just reconnect and it works out 🤷