Lightning Specification Meeting 2023/08/14

[t-bast]

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

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
• Clarify behavior when both optional and mandatory feature bits are set bol09: Specify behavior when a node specifies both optional and required features #1095
• Simplified mutual close option_simple_close (features 60/61) #1096
• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Use scid in blinded paths Reduce size of offer blinded paths #1099
• Offers Offers #798
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments zzz-extension-bolt: a proposal for dynamic commitment upgrades #1090
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Harmonize max cltv_expiry across implementations BOLT4: Specify max HTLC nLocktime for expiry_too_far #1086
• Attributable errors Attributable errors (feature 36/37) #1044
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• 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
• 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 or Websocket address type: attempt 2 #1068

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 draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• Simplified commitment Feature 106/107: option_simplified_update. #867
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• 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
• lnprototest (https://github.com/rustyrussell/lnprototest)

[ariard]

Normally addressed all outstanding comments on #919 and #1086.

Once landed, open to document users-level suggestions in term of fee-bumping reserves management as spec recommendations, that we have been working on the LDK-side.

[devrandom]

I believe there is also a plan to discuss 2-of-2 multisig in the script path for force-close (instead of nested musig). I / VLS support this because:

• there is no significant additional privacy loss, given that force-close already makes things obvious
• force-closing only happens a small % of the time, so the contribution to channel expected fees is small

There may be other advantages to 2-of-2 multisig, including less crypto operations (important for embedded device signers) and reduced commit latency.

In general, the use case that we support (external signers) may require additional round-trip to a remote signer and may involve under-powered signing hardware (e.g. consumer device).

[Roasbeef]

dual funding:

• main thing not implemented in CLN is some reconnection stuff
• eclair waiting on on CLN to update the TLV values, etc -- then can do more interop

splicing:

• CLN shipped experimental splicing, ppl breaking stuff, iterating now with bug fixes
• other testing stuff re expected message exchanges, still fishing around for something to use tool wise
  • could be lnproto test, but needs more work to figure out
• in the end may need to add more TLVs to the splicing msg

mandatory feature bit stuff:

• all don't care rn, but people just shouldn't do it
• related taproot off shoot
  • hard to make things work well with the old implicit negotiation (feature bit negotiation)
  • with a future of multiple chan types, should mainly be doing explicit negotiation
• going with nonces for now (musig2 in funding):
  • commit to implements the multi-sig version in future as FROST impls mature and also get more clarity on nested musig2 interactions

simple close:

• edge: no one has an output
  • so remove it, then require that one side needs to have an output
• closer needs to have an output, other side can abandon it, also need to mind the dust rule as well
• roasbeef to give implementation a shot
• need a dust limit in there?
  • don't include if below the limit, make sure doesn't relay, etc

spec clean up:

• go required first, then see what breaks, can make compulsory after the fact

blinded path QR code shrinking:

• going from 32 byte value to 8 byte value
• smaller, so nice
• also sort of decouples from the long term ID, now using something that's more ephemeral
• implementation able to decide what it wants to use, can use node ID or scid
  • already has the value there, so just change if you can actually set it or not
• blinded path construction
  • question of how construction works or other fields needed?
  • can't add the htlc_max_msat, not included rn, do we plan on adding it?
    • rn a field in the offer, but not the blinded paths payloads?

stfu:

• eclair finished implementing it, don't yet have cross compat with CLN, doing last bit of splicings stuff before cross compat as well
• question about feature bit selection
  • use 163 instead of just 63
  • then gives a way to handle changes as well, only go to the final-final bit once it's super stamped in the spec
  • could be a convention going forward: add 100, to show it's pending
    • could go in the doc of "how to write the BOLTs"

splicing:

• moving along, interop stuff having
• if you have a pending splice that isn't confirmed, do you allow another one to nest as a child?
  • or do you just make the other side RBF it instead?

attributable erros:

• working on interop, have impl from eclair

offers:

• test vectors now up from CLN, invalid+valid test vectors, no surprises so far

taproot:

• expand the on-chain section, HTLCs, breaches, etc
  • additional data needs to be stored, or regenerated: control blocks, taptweaks of the 1st+2nd level
• question about FROST w/ nested musig2
  • revocations still hard-ish, but something something send 10 of them
• lnd to add +100 to the feature bit advertised

[ariard]

Working on a Rust implementation of #1043, though not ready yet for new reviews. Idea to be compatible with other jamming mitigations and being usable for LSP APIs DoS.

Chatted with few smart cryptographers around on the trade-off of crypto-systems, I think I’ll look to specify crypto-systems used as BIPs directly.

[carlaKC]

(incredibly late) transcript: bitcointranscripts/bitcointranscripts#274