Lightning Specification Meeting 2023/02/27

[t-bast]

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

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Fat errors Attributable errors (feature 36/37) #1044
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Splicing Splice draft (feature 62/63) #863
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018 and bolt3: test vector fixes #1056
• 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
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016
• Update static channel parameters zzz-extension-bolt: dynamic commitments #1026
• Liquidity ads option_will_fund: liquidity ads #878
• Sign commitments at various feerates Add option to sign commitments at various feerates (FEAT 32/33) #1036

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.

• 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

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: Upfront Fees to Mitigate Channel Jamming #1052
• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• 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
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

route blinding:

• lnd has interop now in a PR, not yet reviewed
• main PR has been squashed down, ppl to do final pass overs now

onion messaging:

• nearly universal interop?
• questions re how ppl handle the state machine of the non-happy path:
  • fall back if someone critical on the route doesn't support
    • ideally direct connect from there then
  • what about timeouts?
    • not direct signal if you send and packets get dropped, or timedout, etc
    • will need co properly test/control to ensure UX is up to par w/ other solutions

fat errors:

• there, in a holding pattern
• someone from eclair making prototype

splicing:

• eclair working on splicing stuff, made a lot of progress
  • things get hairy when you combine this w/ zero conf....IYKYK (when you get there)
• msat rounding
  • issue where one party needs to round up and the other needs to round down
  • current protocol uses the delta in msat, which then needs to work out properly on chain, or you risk bleeding out a sat or two on chain
• can the msat issue be avoided by just not sending the final amount?
  • just send the inputs+outputs and then let the rest be implicit
  • or you just need to express the fee or fee rate
• will continue to brainstorm what other issue might pop up, etc

taproot channels:

• lnd working thru PR review, in a holding pattern re interop
• secp-zkp PR now approved: Update musig module to BIP MuSig2 v1.0.0-rc.3 BlockstreamResearch/secp256k1-zkp#211
  • others can be unblocked now re giving feedback re APIs, etc

dyn commit

• lnd wanting to revisit, as a way to upgrade ppl to taproot channels, and also maybe across versions if something changes in the future
• CL wanting to revisit as well, since wanting to move ppl over to zero fee anchors
  • also have something custom already for static remote key
• revisiting question of the overlap with splicing
  • eventually splicing has a channel type on it