Lightning Specification Meeting 2022/09/26

[t-bast]

The meeting will take place on Monday 2022/09/26 at 8pm 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

Pull Request Review

• Remove legacy sphinx format BOLT 4: Remove legacy format, make var_onion_optin compulsory. #962
• Update static channel parameters zzz-extension-bolt: dynamic commitments #1026
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Tlv stream in onion failures TLV failure message and length relaxation #1021
• 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
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016

Waiting for interop

• Fix channel pruning behavior
• Channel update flags Bolt7: add channel update flag for scid alias #999
• Grace period for channel closes gossip: delay considering a channel edge deleted for 12-blocks #1004
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• 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

• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• Liquidity ads option_will_fund: liquidity ads #878
• 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
• Upfront payments / DoS protection Hold fees #843 and https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

mandatory tlv onion:

• now about 0.01% using the old format, seems safe to remove the old ones
• new commit to be added to the PR to update the test vectors (remove old, add new specific ones)
• side question of: what's the new actual hop limit?
  • payment secret makes it shorter, and also payment metadata
  • seems to be > 20, but actual limit need to be pinned down, could be future test vector update

#1026 dynamic commitments:

• simpler take, inspired by quiescence/stfu proposal
• doesn't allow to take place w/ HTLCs active
• concerns that something like that would be too limiting:
  • rationale was that recent insights led to the belief that for spicing type protocols, you can't have any HTLCs in the zero htlc anchors land
  • however this is just about the commitment and not the funding output, so no HTLCs active
• related is that you want to be able to properly "reject" certain fields
  • related to ideas to add "suggestions" to the warning message
  • can be used to tell ppl the dust limit is too high or low (or w/e)
  • modification from the current draft, that wants the reply to have bits w.r.t what isn't included
• greater question of splicing as a specific case of dynamic commitments:
  • can kind of separate them into things that change the funding outpoint vs not
  • then in the future splicing can be folded into something like this?
• flow control for HTLCs
  • could be an initial thing to use to start being dynamic
  • no reason for the other party to be able use all 483 at once, flow control, AIMD

zero htlc fee test vectors:

• need one other ACK, then probably ready to go

reviving old convo on pruning behavior:

• eclair went to fix their pruning behavior, realized that if your peer isn't properly pruning they'll send you partial channel updates:
  • you'll revive something, but then will sort of flap and remove all over again
• desire to converge on lnd's pruning behavior:
  • remove if either side is a zombie
  • only revive if the side that pruned is the one that's the one advertising the channel update again

max dust limit value:

• related to dyn commitments stuff
• call for reviewers on this
• related to tx v3 stuff, would allow us to update channels to opt into the new relay policies in the future (w/e they are)

removing the onion TLV message size:

• moving to 256 to 1024 could be a harder change (even though it was a SHOULD), since most implementations have effectively hard coded this value
• so perhaps we just need to upgrade to allow senders to handle, and we can not have to add signalling?
• in theory impls like CL, already support larger values, but needs to be tested out in practice
• action item: figure out how nodes handle them in practice

route blinding:

• CL has the payment aspect working now, has a dummy blinded route at the end (1 hop to me)
  • minimal implementation just replacing the payment secret w/ this
• next step: to implement when you really need one, has a private channel, etc
• for testing, can just provide a custom RPC w/ a bolt12 invoice w/o an offer just to be able to test
  • may not be exposed permanently, but can test all the logic, etc works properly

onion messages:

• few changes to the naming scheme, now mainly wanting to do cross impl testing

impact of changing funding_locked to channel_ready:

• had rippling implications for CL, also in offers they sign the name at times
• lnd never renamed

turn based co-op close:

• wants the warning message to be able to say if the fee is too high or w/e
• alternatively, could just do it s.t you never send sigs until the very end
  • other q's is: does both sides send the sig at the very end?
  • maybe just send it again, or be comfortable with not being able to broadcast
• dual funding+splicing off shoot:
  • splice close proposal, basically being able to close out in a special way (eg: close out into diff channels or w/e)
  • would also have multiple versions, in case the other one never actually fully confirms
• what should actually be the change to closing process?
  • few diff paths on the table: turn based, only send sigs at the end, mega arbitrary closing

interop:

• Bolt7: add channel update flag for scid alias #999 now ready for CL and elcair
• dual funding and channel reserve:
  • for phoenix, the non-initiator gets zero reserve
  • maybe can be done after the fact
• force close on error not chan reest:
  • lnd needs to check this doesn't break the SCB flow
  • CL has a version of this now themselves

[t-bast]

I tested interop between eclair and cln today for #999, we're all good!