Lightning Specification Meeting 2025/05/19

[t-bast]

The meeting will take place on Monday 2025/05/19 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
• Investigate QUIC transport BOLT-0008+BOLT-0007: consider adding QUIC transport #1257
• Gossip infinite loop Gossip Infinite Loop Fix #1256
• 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
• Attributable failures Attributable failures (feature 36/37) #1044
• 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
• 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
• 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
• Dynamic Commitments Extension/dynamic commitments #1117
• 0-fee commitments Zero-fee commitments using v3 transactions (feature 40/41) #1228
• Moderation rules Add newer moderation rules [DRAFT] #1254

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.

• Assume option_channel_type Assume option_channel_type #1232
• 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)

[brh28]

I opened a draft PR this past week for option_path_query and would love to get some eyes on it: #1259

[Roasbeef]

invoice validation strictness:

• added constraint to make sure that d and h are the proper length
• also fail to make sure that

quic chatter:

• lnd ran into some issues, head of the line blocking became an issue for TCP packets
• regression led to blocking for both the reader and writer at the TCP level
• QUIC could be interesting here as a broader solution, that doesn't require more complex application level flow control
  • experimentation elsewhere on a similar topic re Tor:
    • https://dspace.mit.edu/handle/1721.1/128590
    • https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/7KDMJMOUH34AAKYYUVBVBV2Z7YNMUAKI/

"infinite" gossip loop:

• make sure that you don't ping pong announcement signatures forever between each other
• edge case re announcement signature:
  • we send ann sig, you disconnect, I send again, you should send yours again
  • impls should make sure they handle this case
• matters more for splicing, as if you don't get the chan ann propagated within 12 blocks, then can lose the rep

splicing:

• updated thinking re zero conf usage
  • limits on the number of RBF bumps that can be outstanding (limited to 20)
• have cross compat with the batch sig stuff now with CLN, working w/ LDK

attributable failures:

• have an impl in eclair, tested w/ LDK, looking pretty good re interop
• attribute data:
  • would we be interested in having the attribute data in update fulfil as well
  • why only for failures? makes sense to do it for succesful payments as well (more info re how fast a given node is)
• privacy concerns re latency
  • incentives to batch/fuzz in general
  • centralization pressure re latency optimization for path finding
  • should nodes set some min value?
• encoding questions:
  • send the actual number?
  • bucket it?
  • number minus some constant