Lightning Specification Meeting 2023/08/14

[t-bast]

Lightning Specification Meeting 2023/08/14

[carlaKC]

(incredibly late) transcript: bitcointranscripts/bitcointranscripts#274

[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.