Lightning Specification Meeting 2024/06/17

[t-bast]

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

• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• 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
• Offers Offers #798
• 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
• Optional channel_update in error onions Drop the required channel_update in failure onions #1163 or Drop the required channel_update in failure onions #1173
• 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)

[Roasbeef]

sftu:

• to add to the spec: SHOULD disconnect if not complete in 60 seconds
  • general timeout on stfu period
• should we add a message for disconnect?
  * only needed if the initiator isn't doing anything
  * so would we have an application level?
  * or does is just hide other bugs
• eclair + lnd have interop in the latest version
• heading to merge town

liquidity ads:

• designed to be extended in two dimensions
• how to negotiate fees, and how you pay it
  • in the PR, compute: compute fees based on the base fee + proportional, etc
  • how you pay in PR: pay from the interactive tx, etc
• added: when you buy, can say the payment type is from channel balance or future HTLCs, etc
  • so then can pay the fees afterwards
  • later able to look at lease duration, and if you'd change the scripts or not, etc, etc
• note to reviewers: prob better to look at the JSON test vectors
• not to impls: writing code to define the types can also help out

offers:

• have testnet node, can relay + pay and recv, etc, etc
• ready to start cross compat for this version
• lnd doing further work on blinded paths recv+send, have mpp send over multiple blinded paths working
• should we disallow having a node ID if you also have a blinded path
  • use case: able to sign stuff, etc -- but then how you get to me is a mystery
  • may need a spec change, current version doesn't allow both to exist
  • have another encoding format w/ 0x04 or 0x05, basically a new pubkey type that informs how to parse
    • also used to allow a node ID to be there, and as a hint that you should open a channel on the fly, etc
  • also just a pubkey, not necessarily a node ID -- call it something diff?
    • signing_id, signing_pubkey, payment_key, invoice_key ?
• other payer_id value, some apps may want this to stay the same when paying ppl on a contact list
• new project helping w/ interop testing:
  • https://github.com/LN-Zap/bolt12-playground
  • found interop bugs
    • CLN doesn't pay offers that don't have blinded paths
    • something else with differing value amounts, no amount, but description
    • does it test error cases (playground)?
      • if you have a blinded path, but can't relay, or don't have enough liquidity
      • ppl should use the proper errors, wouldn't come up when testing the happy path
• behavior re requesting many paths
  • some try 10 times (or use 10 paths?) when trying to fetch an invoice the first time
• wanting experimental range for TLVs in offers, specific range stuff should be in
  • to carve out a stub range

dyn commits:

• keagan pushing forward w/ impl of the flow control param changes, so stuff like max HTLC, etc, etc
• static remote key now compulsory
  • CLN wanting to give ppl a path to update them, also with legacy anchor
    • has the older version CLN specific to do a custom thing to update
  • what do the others want to do?
  • node ann shows that understand anchor, but not existing chan types
    • could add extra feature bits as telemetry source

taproot:

• to clarify the way you detect a force close
  • can't rely on OP_DROP presence, instead need to do deeper pattern matching
  • to update spec and test vectors

taproot gossip:

• gotta deal with needing to broadcast both until $FUTURE_BLOCK_HEIGHT
• need to circle back in spec re burst budget for block height based rate limiting

compressed bolt 12:

• to be able to pack in more, since merkle tree validation w/ sig validation, etc, etc