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.

• [x] Fix channel pruning behavior -> fixed in eclair, lnd was already fixed, what about ldk and cln?
• [x] Splicing #863
• [x] Dual funding #851
• [x] Route blinding #765
• [x] Onion messages #759
• [x] Offers #798
• [x] Taproot #995
• [ ] ~Fat errors #1044~
• [ ] ~Add dust exposure threshold #919~
• [ ] ~Inbound fees https://github.com/lightning/blips/pull/18 and https://github.com/lightning/blips/pull/22~
• [ ] ~Anchor outputs zero fee htlc txs test vectors #1018~
• [ ] ~Clarify channel_reestablish requirements #1049 or #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 #1016~
• [ ] ~Update static channel parameters #1026~
• [ ] ~Sign commitments at various feerates #1036~
• [ ] ~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 #934~
• [ ] ~Graph dump on gossip_timestamp_filter #980~
• [ ] ~Websocket transport #891~

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• [ ] ~Channel jamming #1043 #1052~
• [ ] ~Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html~
• [ ] ~Quiescence #869~
• [ ] ~Simplified commitment #867~
• [ ] ~Hold htlcs before forwarding #989~
• [ ] ~Trampoline routing #829 and #836~
• [ ] ~Peer storage backup #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: https://github.com/bitcointranscripts/bitcointranscripts/pull/229