Lightning Specification Meeting 2025/04/21

[t-bast]

The meeting will take place on Monday 2025/04/21 at 8pm 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.

• Clarify Bolt 11 invoice requirements Clarify Mandatory Field Length Requirements and Add Note on Low R Signatures in BOLT 11 #1243
• Require minimally encoded Bolt 11 invoices Require minimally-encoded features in BOLT 11 invoices #1245
• Remove CoC Remove the CoC.md (attempt #3) #1248
• Dual funding reconnect commit_sig retransmission Do not unnecessarily retransmit commitment_signed in dual funding #1214
• Allow non-initiator to RBF dual-funded channels Allow either node to send tx_init_rbf in v2 establishment #1236
• 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
• BOLT 12 recurrence BOLT 12: re-add recurrence support. #1240
• 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
• Dynamic Commitments Extension/dynamic commitments #1117
• Attributable errors Attributable failures (feature 36/37) #1044
• Assume option_channel_type Assume option_channel_type #1232
• 0-fee commitments Zero-fee commitments using v3 transactions (feature 40/41) #1228
• Channel jamming draft: HTLC Endorsement to Mitigate Channel Jamming #1071 Project Updates: Hybrid Channel Jamming Mitigation #1218
• Bolt 12 contacts: blip-0042: Bolt 12 Contacts blips#42
• Liquidity ads Extensible Liquidity Ads #1153

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)
• 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)

[ariard]

Re-reading the thread https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493/5. Still think there is something.

[Roasbeef]

bolt 11 features:

• move forward with minimal encoding re feature bits
• merge in with the other

dual funding change:

• waiting for interop tests

splicing:

• proposed changes re batch start + end, needing to handle the message limit issues
  • should it be generalized, or just for this use case?
  • should there be extra validation when reading?
    • if require that stream must be contiguous, then need extra validation re message size
    • what about ping messages, are those allowed in between?
      • main impl challenge depending on codebase arch
    • current draft: 1d5e0ce
      • high level explanation:
        • have multiple active splices, updating them all, batch field added to denote a batch of sigs that should be processed together
  • other idea:
    • transport layer extension to allow > 65 KB messages?
      • would need to starting dealing with DoS issues once again
• zero conf and splicing:
  • w/o zero conf, can have: current output, splicing txn, new update
    • leaves: RBF attempts of splice txn
  • w/ zero conf:
    • can have chains of txns, not necessarily a tree
    • can get splice locked in an async manner
    • can start new splices w/o getting splice locked
  • scenarios:
    • if there a reason to do zero conf for splice out?
      • why not RBF instead of another chained splice
      • if want to do zero conf for everything, must do it everywhere
    • splice in:
    • fee rate race conditions:
      • can be unable to publish own transactions
      • held back on sending splice locked until broadcast confirmed (?)
      • issues re mixing RBF and zero conf (based on current set of rules)
  • splicing txns v3?
    • issues re restrictions re zero conf transactions
  • @t-bast to create issue summarizing the issues w/ txn trees/chain, zero conf, etc

taproot:

• eclair doing refactoring rabbit whole
• lnd working on adding nonces to rbf close, also updated PR for new version

taproot gossip:

• BOLT PR updated, waiting for additional feedback