Lightning Specification Meeting 2025/01/13

[t-bast]

The meeting will take place on Monday 2025/01/13 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
• Peer storage backup Peer storage for nodes to distribute small encrypted blobs. #1110
• Announcement confirmation depth discussion Remove explicit 6-blocks delay for announcement_signatures #1215
• Dual funding reconnect commit_sig retransmission Do not unnecessarily retransmit commitment_signed in dual funding #1214
• 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
• Channel jamming draft: HTLC Endorsement to Mitigate Channel Jamming #1071 Project Updates: Hybrid Channel Jamming Mitigation #1218
• 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 errors (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)

[Roasbeef]

rbf close:

• eclair waiting on lnd for final interop

peer storage:

• pretty much final
• have interop with eclair and CLN
  • eclair starting to work to update to this version
    * ready-ish to land now

ann 6 conf change:

• spec has a value of 6 hard coded right now
• most implementations scale the number of confs from the channel size
• change to allow impls to send ann sig as soon as they consider it confirmed '

splicing:

• moving onto final interop testing between CLN and Eclair
• taproot interaction:
  • if doing deterministic nonces, then want to factor in the splicing transaction as well
  • as is, spec recommends using just the counter for the commitment height
  • but can have many commitment transactions at the same height

taproot:

• comment from t-bast to remove the dep on anchor channels from taproot chans -- basically implicit
  • also means we can remove it from the spec side
• eclair moving forward with implementation, making sure compatible with the TLVs from splicing

channel jamming:

• new master tracking issue: Project Updates: Hybrid Channel Jamming Mitigation #1218

trampoline:

• waiting for cross compat tests between eclair and LDK

inbound fees:

• lnd discovered some degenerate cases with always computing the optimal routing factoring the diff types of inbound fees: [feature]: Proposal for a different cutoff between InboundFee and OutboundFee in pathfinding lightningnetwork/lnd#8945 (comment)