Lightning Specification Meeting 2024/02/26

[t-bast]

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

• 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)
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (2024 is going to be the year of trampoline 🎉)
  • please give your opinion on Trampoline onion format (Feature 56/57) #836 (comment)
• Allow sciddir_or_pubkey for every hop Compact representation for node id #1138
  • please let us know if this is a concept ACK or NACK (we can retract that proposal if folks don't think it's widely useful)
• 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
• Simplified mutual close option_simple_close (features 60/61) #1096
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
  • needs rebase and cross-compat testing strategy (see last comments)
• Splicing Splice draft (feature 62/63) #863 vs 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
• Attributable errors Attributable failures (feature 36/37) #1044
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Offers Offers #798
• 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.

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

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• 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
• Hold htlcs before forwarding Add the ability to hold HTLCs before forwarding (FEAT 52/53) #989
• lnprototest (https://github.com/rustyrussell/lnprototest)

[t-bast]

I won't be able to attend this meeting, but there are some comments and PRs on which I'd like feedback from the crowd (see details in the agenda).

[Roasbeef]

option zero reserve:

• seems straight forward impl wise, just need to worry about fee edge cases

trampoline:

• LDK now has full test vector parity!
  • have the ability to construct trampoline packets
  • building wrappers around it (API wise)
  • now working on constructing a trampoline packet based on a user specification
  • then path finding for trampoline route stuff after
• working off of: Trampoline onion format (Feature 56/57) #836
• some trampoline related edge case w/ zero amount invoices?

multi-format for chan ID + node key:

• reduces the size of the offer
• not useful for a long lived QR code, but nice to be able to reduce QR code size
• waiting on interop

blinded paths:

• what do ppl do for max CLTV expiry for a blinded path?
• while testing lnd interop, ran into a zero value
  • zero value doesn't make sense, was an older version?
  • potentially bug, odd, looking into it

DNS based offers:

• need to follow up on the offers side of things
• will rip up the current design and replace it w/ just including the user and domain part in the invoice request
• next step after:
  • define some sort of bLIP type range for the offer and the invoice request

coop close:

• lnd close to interop, final unit tests

stfu:

• lnd + eclair working on interop testing
• wanting to instead test w/ something externally observable:
  • so may wait for splicing or other to be able to test properly
• main important thing: stfu goes away when you reconnect
• how does stfu work w/ resume?
  • when you receive a signature for a splice, then assume that stfu is done
  • should there be another message to ack/conclude the stfu'd state? ok? stfu_terminate
    • not there rn, as was for a simple case where you just want to reconnect
    • edge cases?
      • cases where the splice can't be abandoned?
      • interacts with chan_reest in the context of splicing as well
• should elevate stfu to be on a higher level, so has its own control flow
  • then allows it to be combined with other protocols

splicing:

• dusty working on a new scripting tool, to be able to declaratively communicate batched splices
• initial splice command has a chain hash, but no longer need it already have the chan_id
• before had dodged the post splice reserve problem, now wanting to tackle it:
  • few ways of handling it:
    • treat as a fresh channel
    • follow the old channel reserve requirements, until new is met post splice
    • drop it entirely
      • can also be done via the zero reserve channel type (you say channel type during splice?)
      • restrictions should be the most strict of all the splices happening at the moment
• divergence w/ dyn commit and splicing:
  • trying not to go to chain w/ re-anchoring
  • splicing can also include a channel type in the message

taproot:

• eclair working on a version

offers:

• scid or pubkey
• human readable stuff crossing over w/ DNS, need to work out

[t-bast]

some trampoline related edge case w/ zero amount invoices?

Can you detail that? I don't see what edge case exists here?

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#442