Lightning Specification Meeting 2025/03/10

[t-bast]

The meeting will take place on Monday 2025/03/10 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.

• Improve Bolt 5 preimage check Check for preimage before failing back missing HTLCs #1233
• Assume option_channel_type Assume option_channel_type #1232
• Dual funding reconnect commit_sig retransmission Do not unnecessarily retransmit commitment_signed in dual funding #1214
• Attributable errors Attributable failures (feature 36/37) #1044
• 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
• 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
• Dynamic Commitments Extension/dynamic commitments #1117
• Bolt 12 contacts: blip-0042: Bolt 12 Contacts blips#42
• Liquidity ads Extensible Liquidity Ads #1153
• 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)
• 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)

[joostjager]

Would like to share a short update on attributable failures. I need to leave early, so it would be great if I can take a few mins somewhere in the first half hour of the meeting.

[ariard]

#1233

https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493/4

This is a non-sense as a routing LN node cannot make assumptions that a LN channel counterparty will accept to interact off-chain to remove a received HTLC on an incoming channel. Both the LN counterparties on the incoming and outgoing channels can be malicious. Instead it should be layout decision heuristics to go on-chain or not in function of the HTLC value and the on-chain feerate cost @t-bast

[t-bast]

I'm not sure what you're suggesting we change, I don't understand your point...sure, when you fail upstream the remote node may be unresponsive, but at that point you just force-close the upstream channel as well?

[ariard]

I'm not sure what you're suggesting we change, I don't understand your point...sure, when you fail upstream the remote node may be unresponsive, but at that point you just force-close the upstream channel as well?

Check my answer on the delving bitcoin thread @t-bast.