Lightning Specification Meeting 2023/09/25

[t-bast]

The meeting will take place on Monday 2023/09/25 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.

• Experimental feature bit recommendation CONTRIBUTING.md: modern feature bit assignment. #1108
• Clarify offered and negotiated features BOLT 1: define what offered and negotiated mean. #1109
• Clarify max_htlc_value_in_flight_msat Clarify the semantics of max_htlc_value_in_flight_msat #1113
• Harmonize max cltv_expiry across implementations BOLT4: Specify max HTLC nLocktime for expiry_too_far #1086
• Simplified mutual close option_simple_close (features 60/61) #1096
• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Offers Offers #798
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments zzz-extension-bolt: a proposal for dynamic commitment upgrades #1090 vs Upgrade on reestablish BOLT 2: upgrade protocol on reestablish #868
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Attributable errors Attribution data (feature 36/37) #1044
• Clarify channel_reestablish requirements Clarify channel_reestablish requirements #1049 or Rework channel_reestablish requirements #1051

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
• Liquidity ads option_will_fund: liquidity ads #878

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.

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• Websocket transport websocket address type: allow transport over RFC6455 #891 or Websocket address type: attempt 2 #1068

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• Simplified commitment Feature 106/107: option_simplified_update. #867
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Hold htlcs before forwarding Add the ability to hold HTLCs before forwarding (FEAT 52/53) #989
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• lnprototest (https://github.com/rustyrussell/lnprototest)

[t-bast]

I won't be able to attend this meeting, but I'll review most PRs before that. I started working on option_simple_close in ACINQ/eclair#2747 which means I have a lot of feedback on that one!

[Roasbeef]

simplified close:

• lots of initial review by t-bast, few iterations, now enshrines the dust rule amongst other things
• now working on getting an initial implementation going
• roasbeef still has on his list to take a look at, and also start with a basic implementation

clean up feature bits:

• want to start to make compulsory first, then later on see if we can start to ignore them
• CLN starting to make all the features compulsory, will do for next release (winter-ish)

CLN anchor inflight upgrade:

• using old method used to upgrade, uses the stfu message now
• uses a TLV in the chan_reest message, says to upgrade chan then goes from there
  • assumes having nothing to retransmit
• can also use stfu to force if needed, "special" case of a no param update, so nothing else that needs to be sent

stfu message:

• needed for splicing, dyn commits and all other stuff
• may have identified an edge case where the channel actually never fully clears out
• rusty to take a look at the edge case, see what type of rework is needed

taproot:

• LDK waiting on next release, then can pick back up
• gossip work to pick back up in the next week or two

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#282