Lightning Specification Meeting 2023/02/13

[t-bast]

The meeting will take place on Monday 2023/02/13 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
• 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)

[t-bast]

I won't be able to attend this meeting, but I will report on cross-compatibility test results between cln and eclair for dual funding before the meeting starts.

[t-bast]

Dual-funding cross-compatibility has been successfully tested between eclair and cln 🎉 🎉
A bit more details are available here: #851 (review)

[joostjager]

Highly Available Lightning Channels: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html

[TheBlueMatt]

I will be on a plane for this meeting, sadly.

[Roasbeef]

blinded paths:

• lnd doing interop testing now, using lnd to forward a blinded path route to CLN

onion messaging:

• starting to do interop testing for the flow of offers, but not the payment part yet

taproot:

• LDK now pushing towards interop testing
• laolu still needs to push out the lates script changes

attributable errors:

• formerly known as "fat" errors

• now the TLV portion merged in, joost posted some additional rationale w.r.t why TLV

  • sender doesn't need to reveal characteristic about what they can interpret
  • nodes can just now return what they want, maybe with some priority ordering (?)
  • in case there isn't enough space, then routing nodes can make a decision about what's most important to return

• TLV ftw!

• dust exposure:

  • now updated to latest commit: 7705356
  • still needs ppl to take a look at

splicing:

• working on re-working the protocol to use distinct messages
  • was gonna use the channel ID, now just use the txid of the splice transaction
  • now used as the main identifier, now use that TLV in commitment signed
  • do you ever change the channel ID? no...a bit too tricky, is a universal identifier
  • what about invoices (scid)?
    • changes, maybe can just use scid aliases to make it easier?
    • also have a grace period, 6 blocks before forgotten
• new issue discussed:
  • partial mstat balance
  • then space in
  • what to do with it?
  • just hand it to miners, so at most 1 sat -- give it over to fees

CLN version of peer back up protocol:

• messages: 7 and 9
• has a blob other peer can store, then another message to return the blob
• experimental option in upcoming release, odd message -- some other thing going on
• eclair has version for?
  • Peer backup storage (feature 40/41/42/43) #881
  • might be in chan reest (their version)
  • CLN version sends it before re-establish
    • is this counter to the spec?
    • no, since not specific to a given channel, just a blob of data, sort of just on the gossip later
• questions:
  • blob size restricted?
    • single message so 65k limited, srs node should have srs back up
  • how's it find the nodes?
    • got to the gossip network, potentially rediscover them
    • only private channels, would have more difficulty (especially if changed IP addrs)
    • something something sats backup, 65 KB storage slot

high availability channels:

• to prove that peers are serious
• can establish a view of the network totally, anyone can advertise
• if it's a free signal, then not costly at all, so why wouldn't everyone just set it?
• idealized to be a property of a direction instead of a channel

channel jamming:

• have been running meetings every other week
• carla has been taking the new chaincode paper to try to turn it into a spec/implementation
• early unconditional push fees along route isn't going to work
  • as you start to accumulate fees if you have high/low fees then ppl can just start to take the fee
  • if upfront fee > normal fee, then node would just always take
• proof of forward:
  • now trying to go back into approach where need to prove that you can settle the preimage
  • if you try to route and have two attackers, then can just take (can you if PTLC?)
  • also leaks forwarding information now, since if you fail back, then you never got it down far enough
• ppl now working on the endorsement and the unconditional push independently
  • may be trying endorsement with experimental feature bit, possibly run in read only mode

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#232