Lightning Specification Meeting 2023/01/30

[t-bast]

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

• Fix channel pruning behavior -> fixed in eclair, lnd was already fixed, what about ldk and cln?
• Splicing Splice draft (feature 62/63) #863
• 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
• Inbound fees Inbound routing fees blips#18 and Add a bLIP for backwards-compatible inbound fees blips#22
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018
• 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.

• 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
• Sign commitments at various feerates Add option to sign commitments at various feerates (FEAT 32/33) #1036
• Liquidity ads option_will_fund: liquidity ads #878

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
• Graph dump on gossip_timestamp_filter Inconsistent behavior around graph dump on gossip_timestamp_filter. #980
• 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)

[carlaKC]

I'd like to record the meeting for the sake of generating a transcript from the video.

I'll ask again on the call, but wanted to give folks the opportunity to voice objections here as well.

[Roasbeef]

splicing:

• update message race conditions
  • messages pre conf, valid afterwards
    • once a prior splice confirms, when do you stop sending the sigs for the old versions?
  • current proposal isn't atomic, as is never have HTLCs
  • issue w.r.t switch over, re when to start to use the new version of the commitment transaction
• today have a TLV that sends all the sigs for all the versions
  • potential risk that gets too large, otherwise hit the message size limit
• potential work around
  • use a distinct commit sig message for each active version
  • can then use a new identifier to reference which version of the commit tx

htlc max update issue:

• potential fragmentation in network, can resolve however, future feature bits

resolving SCB issue:

• not as easy as we thought, some other lingering edge cases

taproot:

• NUMs point:
  • sort of degrades the static remote key
  • can move to NUMs point instead, have code that replicates
    • https://github.com/lightninglabs/lightning-node-connect/blob/master/mailbox/numsgen/main.go
  • related thread re back ups:
    • https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html
    • potential issue:
      • have to derive every key from your node ID
      • for CLN, breaks existing security model where they can do mainly hardened derivation for everything
        • would mean the process or w/e dealing with a single channel needs to have access to the private key
• CSV 0 trick
  • current script:

    <remotepubkey> OP_CHECKSIG
    OP_CHECKSEQUENCEVERIFY
    

  • what happens if the first sig is invalid?
  • should it be explicit or ok with the cute trick?
    • explicit would be 1 OP_CHECKSEQUENCEVERIFY
  • other question: plug it into mini script and see what it comes up with?

blinded paths:

• latest version of CLN has modifications to blinded paths, now merged in
  • had an issue of assuming that a route was actually to a dead end
  • distinction between route hint and blinded path, current version uses the same logic for both of them
  • if only one choice to have a path, then should just do anyway
• mpp with blinded paths
  • logic to be updated to do the right thing: actually do the splitting
  • CLN working on a new pay plugin, to do fancy min-cost-flow stuff and revamp iti generally
• eclair <-> CLN interop achieved!

offers:

• new version for introp w/ CLN <-> eclair

dual funding:

• CLN working on finalizing e2e tests

the "oakland protocol":

• high level method to make probing more difficult
• has anyone started to do it?
  • easy step: restrict max HTLC in flight to lower than total channel size
    • eclair: 45% of total capacity for given HTLC
    • LDK <-> CLN: introp re opening less than 100k, LDK doesn't have a floor

channel jamming:

• initial draft spec PR up
• had call last week, summary posted on the ML
  • some new open questions in the email summary: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003834.html
  • stuff to think about before the next meeting
• if we go on the up front fee route, how far do we want to go along the "proof of forward" route
  • high fee node has high upfront fees, so why wouldn't they just take and forward?

[carlaKC]

Full transcript: bitcointranscripts/bitcointranscripts#229