Lightning Specification Meeting 2026/03/09

[t-bast]

The meeting will take place on Monday 2026/03/09 at 8pm UTC 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.

• Splicing Channel Splicing (feature 62/63) #1160
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 70/71/72/73/74/75) #1059
• 0-fee commitments Zero-fee commitments using v3 transactions (feature 40/41) #1228
• Clarify that offer_amount cannot be 0 BOLT 12: clarify that offer_amount must be greater than zero #1316
• Bech32 compatibility with BIP173 BOLT 12: Inconsistent bech32 padding validation across implementations #1281
• Bolt 11 test vector for high-S signatures bolt11: add new test vector high-S signature with 'n' field defined #1298
• Bolt 12 payer proofs BOLT 12: first draft of payer proofs #1295
• BOLT 12 recurrence BOLT 12: re-add recurrence support. #1240
• Bolt 12 contacts: blip-0042: Bolt 12 Contacts blips#42
• Liquidity ads Extensible Liquidity Ads #1153
• Channel jamming Project Updates: Hybrid Channel Jamming Mitigation #1218 Outgoing reputation and HTLC Accountability #1280
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (or mini-trampoline from BOLT 4: add minitramp support. #1292)
• Async payments Support async payments in BOLT 12 #1149
• Dynamic Commitments Extension/dynamic commitments #1117

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.

• Receiver-side random delays Add recommendations for receiver-side random delays #1263
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• 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)

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)
• Investigate QUIC transport BOLT-0008+BOLT-0007: consider adding QUIC transport #1257

[Roasbeef]

bolt 12 contacts:

• Father along, have an implementation w/ eclair and CLN
• Written as a bLIP right now, close to being able to do real world testing, interop, etc.
• questions re:
  • how to manage the fetcher secret (?)
  • eclair has a determinsitic version

path finding:

• t-bast on op tech was saying that they change path finding to go for the least capacity one
  • opposite of what CLN does
    *eclair path finding behavior:
  • if amt falls below a threshold, they send an chan update to modify the htlc mac
  • based on rene's ideas
  • most path finding impls try to maximize the larger public channels
  • may have a low public balance, but high private balance, ppl maybe don't route thru those -- so they want to consume the high balance
  • when sending they used the one with a lower balance, as then they can keep the higher balance ones (maybe public), then use those instead
  • they don't disable the channel, but send an update to update htlc max value accordingly (based on bucket ranges)

constant size packets:

• rusty implemented in CLN now, the lower level option (so not using TLVs)
• need to pick some constants re the packet size, etc
• elias closed the other PR for now, investigating rusty's approach

onion messaging replay protection:

• gijs to make a spec PR to add onion replay TTL via block height
• no onion messaging replay right now
  • can even be in memory, probabilistic, etc, etc

trampoline:

• do we care about the errors that blinded trampoline returns?
• always in the onion in trampoline
• is there some other probing vector that can happen?
• very subtle:
  • deserves a comment and spending time on it
  • need to think a bit about it to properly analyze