Lightning Specification Meeting 2022/11/21

[t-bast]

The meeting will take place on Monday 2022/11/21 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.

• Use onion amount in MPP set calculation Use onion amount in MPP set calculation #1040
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851 -> decide ordering of tx_signatures
• Tlv stream in onion failures TLV failure message and length relaxation #1021
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Route blinding Route Blinding (Feature 24/25) #765 -> should we allow 0-hop blinded paths?
• Fat errors https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html
• Sign commitments at various feerates Add option to sign commitments at various feerates (FEAT 32/33) #1036
• 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.

• 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 and BOLT#02: change SHOULD to MUST for fee-range mismatch #1039
• Update static channel parameters zzz-extension-bolt: dynamic commitments #1026

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: https://eprint.iacr.org/2022/1454.pdf
• 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
• 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)

[joostjager]

Initial version of fat errors as a BOLT pr: #1044

[t-bast]

I might be a bit late tonight, I'll join as soon as I can.

[joostjager]

Have to say that I find Jitsi working better than IRC. But also if you look at the speaker stats, there's just a few people talking a lot. Can imagine that there are others who'd also like to add something, but don't because of latency, different native language, not being sure if the comment is good enough or something else. Also the lack of logs is not ideal.

What I would find interesting to see is how this meeting would work out on a chat medium that allows threading. Multiple discussion branches can co-exist without the confusion that you get on IRC, so perhaps it's better.

[cdecker]

The problem with threading these discussions is that humans are inherently single-threaded, and we'd end up missing discussions to which we'd have things to contribute because they happen concurrently :-)

That is less of a problem with threaded discussions that are asynchronous (ahem... pull request comments ^^)

[harding]

Also the lack of logs is not ideal.

I just wanted to echo the above. I can easily understand how video chats are better for those actively working on the spec. For me, as someone mostly just monitoring progress, having text logs that I could quickly skim was really nice. I'm not suggesting y'all switch back to IRC if the video chats are working well---but, if the benefit to them ever becomes marginal, I wanted to note that the previous format was nicer for at least one person. :-)

[vincenzopalazzo]

Please do no switch to the text again, read with a screen reader is painful, and it is impossible to use in chat like IRC or equally.

If we want something written we can use ML to write down the video.

[t-bast]

I agree that having logs of everything that was said is quite valuable, we used to have that with people writing transcripts for the spec meetings when we started doing video again. I think @vincenzopalazzo is right, we should record the video meeting and use a tool to generate the transcript, that's definitely worth a try.