Lightning Specification Meeting 2022/05/09

[t-bast]

The meeting will take place on Monday 2022/05/09 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

• Onion failures with channel updates Clarify onion failure data encoding #979
• Clarify mutual close requirements bolt2: shutdown adventure #985
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Port conventions for different networks BOLT 1: introduce port convention for different network #968
• gossip_timestamp_filter behavior clarification Inconsistent behavior around graph dump on gossip_timestamp_filter. #980

Waiting for interop

• Simple turbo channels enablement Explicitly allow funding_locked early, and support alias scids (feat 46/47/50/51) #910
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Websocket transport websocket address type: allow transport over RFC6455 #891
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• Dynamic DNS support in gossip messages BOLT 7: add gossip address descriptor type DNS hostname #911

Long Term Updates

• Liquidity ads option_will_fund: liquidity ads #878
• Splicing Splice draft (feature 62/63) #863
• Simplified commitment Feature 106/107: option_simplified_update. #867
• 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
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip
• Taproot updates

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)

[ksedgwic]

Was there a calendar invite for this meeting? I think I tried one last time but it had bugged permissions?

[vincenzopalazzo]

Here we go the calendar

Sorry for the last time!

[Roasbeef]

Interop update:

• Eclair ready to do dual funding interop w/ CL needs an updated version to test against.
  • Re RBF: CL has an RPC mechanism to trigger an update
  • Has some cross over with splicing potentially

On splicing:

• Half baked idea from roasbeef: re-use the anchor outputs in the splicing transaction to give verifiers an on-chain signal that this is actually a splicing transaction. A channel_announcement would then signal explicitly if the channel is splice-able or not
  • Another on-chain: just re-use the multi-sig keys, so then people 100% know it's a splice

[Roasbeef]

Zero conf:

• From decker working on it: what if some features in the channel type TLV were optional, able to flag "maybe" zero conf, then the responder can signal if they accept it or not (?).
• From eugene: doesn't specify that you shouldn't chose alias A if it conflicts with a pre-existing or future channel (seems to be underspecified)

[TheBlueMatt]

From decker working on it: what if some features in the channel type TLV were optional

Yes, maybe we should consider that. This is orthogonal, though.

able to flag "maybe" zero conf, then the responder can signal if they accept it or not (?).

Yes, just dont set the 0conf channel type bit. This is an important part of the spec, yes, LDK will never set the 0conf channel type bit, and Rusty had previously said CLN is unlikely to as well. Nodes can always accept a channel at 0conf with or without the 0conf channel type bit.

From eugene: doesn't specify that you shouldn't chose alias A if it conflicts with a pre-existing or future channel (seems to be underspecified)

Yes, definitely something you need to consider while implementing, not sure that it really needs to be specified, don't shoot yourself in the face, though, obviously.