Lightning Specification Meeting 2023/01/16

[t-bast]

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

This section contains changes that have been opened or updated recently and need feedback from the meeting participants.

• Clarify channel_reestablish requirements Clarify channel_reestablish requirements #1049 or Rework channel_reestablish requirements #1051
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Inbound fees Inbound routing fees blips#18 and Add a bLIP for backwards-compatible inbound fees blips#22
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Fat errors Attributable errors (feature 36/37) #1044
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018

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.

• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• 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.

• Fix channel pruning behavior -> fixed in eclair, lnd was already fixed, what about ldk and cln?
• 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
• 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
• Splicing Splice draft (feature 62/63) #863
• 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]

chan reest scenario:

• lnd has a temporary work around, can just start to send the error the very first time
• CLN also working on fixing some things in their flow as well, they recently added a similar recovery flow
  • will also have a grace period before they force close
• t-bast working on a bigger refactoring of the entire section, in an attempt to make the entire section clearer

dual funding:

• some small changes, added recently:
  • Lisa's suggestion that when you send a tx abort, the peer that received it should echo it back
  • also makes it easier to know when one is leaving STFU mode
  • related to ensuring stuff like cancelling RBFs work more reliably
• matt morehouse making more progress for lnd
• CLN progress: new PR up, tests there mostly working, changed some aspects w.r.t accept_channel2, etc
• LDK progress: existing contributor picking up, still pretty early

inbound fees:

• another instance now by telling you peer to increase/decrease their fees
• some suspect won't be as popular as ppl think it will be: we've given them a new knob, but how well will it work out in practice?
  • how popular will it actually become if ppl just do the experiment?
• difference in the deployment horizon as well
  • p2p: need all your channel peers to update
  • gossip: only need the sender to update

route blinding:

• CLN and Eclair doing direct interop, working on fixing some of the interactions
• lnd has a few PRs up now, targeting 0.17 (the next next release, last was 0.15.5), focusing on getting the forwarding logic pinned down first
  • also able to send/recv now with some lnd works?
  • PR now up to allow nodes to pay blinded routes, need to work out some final kinks

offers:

• CLN modified version in latest release, broke recently, now focusing on more interop

fat errors:

• not much happened since then
• ppl now interested in being able to signal the structure of the error (max number of hops, max size in payload)
  • or if you use diameter + 1, you're not really leaking anything? diameter seems to be about 7 or so in the network today
  • would make it more flexible generally
• number of dimensions: number of hops, and the length of the payload -- they need to sign over a set of possible message lengths

taproot:

• secp-zkp now working on v1.0.0 support!! Update musig module to BIP MuSig2 v1.0.0-rc.3 BlockstreamResearch/secp256k1-zkp#211
• LDK and lnd now pretty close to doing interop, new PR up against: bolt-simple-taproot: make funding symmetric, add new type for shutdown Roasbeef/lightning-rfc#5
• lnd trying out a way to not have to write local secret nonce to disk:
  • using the existing shachain state to derive the nonce (no extra state)
• change to co-op close flow:
  • responder just always accept w/e the initiator says
  • degenerate case of: fee rate too low (can also force close there), so should at least recognize the range
  • should at least observe the low end of the range, want to make sure it's able to get in the mempool