Lightning Specification Meeting 2024/05/20

[t-bast]

The meeting will take place on Monday 2024/05/20 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.

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Optional channel_update in error onions Drop the required channel_update in failure onions #1163
• Offers Offers #798
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
  • @rustyrussell can you (or someone else with access to the branch) rebase the PR? We've started cross-compat tests between eclair and lnd, it's looking good, so we should be able to merge it soon
  • there are also a couple of comments asking for some small additions to clarify a few subtleties, but nothing major
• Splicing Splice draft (feature 62/63) #863 Channel Splicing (feature 62/63) #1160
• Liquidity ads option_will_fund: liquidity ads #878 Advertise liquidity ads rates #1145 Extensible Liquidity Ads #1153
• Dynamic Commitments Extension/dynamic commitments #1117 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
• Async payments Support async payments in BOLT 12 #1149
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071 blip-0004: experimental endorsement signaling in update_add_htlc blips#27
• DNS-based offers Define a mechanism for looking up an offer from a user/domain pair #1136
• Attributable errors Attributable errors (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.

• Constant size failure onion decryption BOLT04: Add rationale for constant error decryption. #1154
• 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.

• Simplified mutual close option_simple_close (features 60/61) #1096
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• 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)

[t-bast]

I won't be able to attend this meeting (I'll be on vacation during the beginning of next week), I've reviewed pending PRs and updated mine, looking forward to your comments!

[ProofOfKeags]

Quiescence #869
@rustyrussell can you (or someone else with access to the branch) rebase the PR? We've started cross-compat tests between eclair and lnd, it's looking good, so we should be able to merge it soon
there are also a couple of comments asking for some small additions to clarify a few subtleties, but nothing major

Here is the PR that clarifies the aforementioned subtleties: rustyrussell#15

[Roasbeef]

offers:

• change to have a blinded path or a node ID
• wanting node ID to be optional if a node ID exists

set reconciliation:

• something to be picked up again once taproot gossip is a thing
• everything will be block height based, timestamps not compatible with approaches

gossip 1.5:

• CLN working on a version
  • also looking forward to block height based rate limiting as well
• legacy channel broadcast
  • how long do we broadcast both of them?
  • also question of the block height buffer as well
    • does this add additional state?

stfu:

• have done prelim introp testing w/ lnd and eclair
  • not fully tested in context yet, but able to verify traffic stops and deferred stuff is reconciled on reconnect
• PR to rusty's branch to clarify some additional requirements: require quiescence sessions to be single-use rustyrussell/lightning-rfc#15
  • clarifies how down stream protocols should interpret cool

splicing:

• new splicing PR: Channel Splicing (feature 62/63) #1160

liquidity ads:

• main PR: Extensible Liquidity Ads #1153

dyn commitment:

• discussion re diff upgrade paths: https://delvingbitcoin.org/t/upgrading-existing-lightning-channels/881/1
• proposal to split off the kick off stuff, depends on appetite
  • also the vector to update just normal channels to anchor zero fee

taproot:

• in interop mode

peer storage backup:

• lnd implementation on going
• LDK implementation WIP now as well, CLN implementation going thru iterations
• ready for fresh review

channel jamming:

• updated the bLIP, call for another round of review
  • close to merging it

rbf coop close:

• waiting for interop re lock time change