Lightning Specification Meeting 2024/05/06

[t-bast]

The meeting will take place on Monday 2024/05/06 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
• Channel closing block delay follow-up gossip: 12-blocks delay channel closed follow-up #1156
• Constant size failure onion decryption BOLT04: Add rationale for constant error decryption. #1154
• Notation for math content BOLT-04: replace quotation marks used in math expressions #1158
• 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
• 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.

• 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)

[ellemouton]

Re taproot gossip: posted some questions in the PR & pushed some updates.

#1059 (comment)

Main question is around the use of the new messages for both existing, legacy channels & new, legacy channels

[valentinewallace]

Re: trampoline, would like to discuss this spec feedback on trampoline <> blinded paths: #829 (comment)

[Roasbeef]

channel update error issues:

• potentially can fingerprint senders by sending out unique channel_update values
• should we remove it all together?
  • would eliminate a finger printing vector
  • but, may add additional UX issues, as not able to get the latest update at runtime
  • can affect mobile nodes that aren't syncing gossip all the time, if they can't get the latest updates, payments may never happen
• can do in two phases:
  1. say it's optional for now
  2. remove the text about applying and broadcasting

BOLT 12 stuff:

• CLN doesn't do direct connect for invoice replies, just for sending
  • would say not connected, can't reply, working on adding that portion
• Offers #798 (comment)

trampoline:

• question re interaction of blinded paths + trampoline
• async payments interaction:
  • looks like sender is setting the CLTV
  • async payments wants a very long CLTV
  • maybe looking at letting a trampoline node extend it themselves

stfu:

• seems that won't be adding termination?
  • for all updates, you have a state where you get to be half committed
  • can't abort, but only one side has exchanged secret data
  • can always end up here during disconnect, handled during channel reest
  • if we add go-on, then we can end up in a half committed state if you haven't d/c'd from peer?
    • do you put chan reest mid protocol?
    • or can try some state sync protocol
    • why go thru the extra effort?
    • instead centralize logic, and use disconnect/chan-reest otherwise

splicing:

• new splicing PR!!
  • old one was still in draft, latest here: Channel Splicing (feature 62/63) #1160
• still have a dep on stfu

liquidity ads:

• working on a PoC of JIT channels
  • flexibility in how you pay, liquidity ads used to advertise fees
  • how would ppl reject?
    • phoenix: set a fee budget, automatic accept, otherwise fail
      * t-bast working on bLIP for JIT channel open
  • includes a will_send_htlc message, has the onion, proves there's actually an HTLC, etc, etc

gossip v1.5:

• motivation for old+new channels in v1.5?
  • block height for channel updates
    • can add to old chan update?
  • also need re-negotiation logic as well
  • effectively double gossip traffic until a future switch over date
• gives migration path away from old gossip for all chans

[carlaKC]

bitcointranscripts/bitcointranscripts#481