Lightning Specification Meeting 2026/01/12

[t-bast]

The meeting will take place on Monday 2026/01/12 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.

• Dust limit recommendations Add details for post-anchor dust_limit_satoshis #1301
• Dual funding reconnect commit_sig retransmission Explicit commit_sig retransmission for interactive-tx #1289
• 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 70/71/72/73/74/75) #1059
• 0-fee commitments Zero-fee commitments using v3 transactions (feature 40/41) #1228
• Bech32 compatibility with BIP173 BOLT 12: Inconsistent bech32 padding validation across implementations #1281
• Reject empty offer_chains BOLT 12: clarify that empty offer_chains must be rejected #1306
• 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
• Network Message padding BOLT1: Add support for network message padding (feature ??) #1304
• 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

[t-bast]

I'm sorry, I won't be able to make it for the meeting this week...here is what I wanted to discuss, and the action items I'd like to see progress on:

• we've got interop working for Taproot channel with @Roasbeef 🎉 : I have a comment pending on the PR to do some clean-up related to mutual close, but after addressing that it's ready to go IMO
• we're working on a few interop issues with cln for splicing, which are tracked in [Splicing] Cross-compatibility test results ElementsProject/lightning#8705: once those are addressed, the splicing PR should be ready to go 🔥
• but we need to merge Explicit commit_sig retransmission for interactive-tx #1289 and Allow either node to send tx_init_rbf in v2 establishment #1236 before splicing because splicing depends on them and they'll cause conflicts: please @ddustin @rustyrussell can you check if cln is ok with those changes and ACK the PRs?
• 0-fee commitments (Zero-fee commitments using v3 transactions (feature 40/41) #1228) are still IMO ready to go, with LDK and eclair having interop, but maybe we'll want more implementations to take a look?

[Roasbeef]

dust limit change:

• impls working to prio

interactive re connect:

• still waiting on dusty to get back to t-bast interop
• similar re 1236: have eclair ack, waiting on some CLN interop, PR up, hasn't been merged yet

splicing:

• super close
  • new updates for splicing for updates
  • LDK <-> eclair interop is there, but LDK do splicing RBF yet, so can't interop on that phase of things
    • part of the splicing spec, if you don't implement it, will get stuck when it comes to an increase of fees
  • CLN waiting on the interop

taproot + gossip:

• eclair + lnd interop!
• now can do positive fees on the gossip side of things
  • also can drop negative fees? or maybe it's still desirable

zero fee transactions:

• when can we start to rely on it?
  • ppl watching and doing active tests to see how reliably the txns can get mined
• impls will need to check to make sure the backing node
• bitcoind removing carve out
  • will laggards expose them to the old attacks that were cleared up by having carve out

offer spec update:

• clarify the spec side of things, want to update the test vectors -- likely will apply as is

high s change:

• lnd has PR for, more of a uniformity thing

bolt 12 payer proofs + recurrence +

• being reviewed rn, rusty to take in feedback to iterate
• rusty hopping on recurrence again
  • ppl like credit card where ppl pull money out of your wallet
  • have had the push in CLN for a while, just an experimental feature
  • rusty to write plugin helper to handle a lot of the mechanics here
  • interesting UX cases around it generally

message padding:

• why not ping?
  • need the equal length coverage first
  • if can control the flushing capabilities, can write a single packet w/ multiple messages?
  • difference of approach: high level vs low level:
    • low level: control socket writes and buffering, append ping as needed
    • high level: pad out all packets
• TLV approach
  • not evenly distributed in the spec as some messages have TLVs defined
  • ppl will try to continue to read past known TLVs, then