Lightning Specification Meeting 2023/07/31

[t-bast]

Lightning Specification Meeting 2023/07/31

[jkczyz]

I drafted a small PR (#1099 based on #798) to allow using scids in an offer's blinded path, as discussed last meeting.

[t-bast]

I won't be available for this spec meeting either (yay french holidays) but I'll review most PRs before that!

[Roasbeef]

simple close chans:

• will people implement this before or after taproot channels?
• how do we want to handle the feature gating here?
  • as is, it just assumes this is the "thing" and doesn't have any feature bit negotiation
  • in the form of two commits: adds it all, then removes the old
    • gives people an option w.r.t what they want
      • should it be the only way for taproot?
• shutdown retransmission:
  • if you reconnect, then you can send shut down again
  • will always start with the shutdown sequence with the nonce
• what to do if no one cares about their output?
  • allows either party to omit their own? or only if it's higher
  • what about the dust values?
• game theory?
  • paying for own thing, so want you to pay vs not
  • normal case, opener is paying all the fees
  • what if you really don't want to pay?
    • propose fee that's below 1 sat/byte, or a zero fee close
    • then you sign off
    • but already the same with the current force close hijinks?
    • doesn't the existing dust field allow us to figure things out?
    • diff is you know exactly how much it'll cost to spend it
      • so then ends up being a way to late bind the dust values
• op_return
  • allow both sides to just say they don't want the channel
  • in practice, just close on min fee and let propagate, this is the nuclear scenario where don't care about

optional + require bits:

• undefined what to do if someone sets both
• people seem to not care about it rn? maybe in the future we can pick an interpretation for it?

cleaning up features:

• perhaps we just make a jump to required first? then revisit afterwards
• then later on can set the new assumption behavior

attributable errors:

• have clearer scope, looking to reduce the hmac size
• needs spec updates, lnd impl to be updated, then waiting for interop w/ the rest

onion messaging:

• has interop, working on more interop
• LDK working on test vectors

offers:

• needs test vectors

dust exposure:

• rusty promises that he'll review it today

taproot:

• FROST questions re nested musig vs not

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#270

[t-bast]

simple close chans:

• will people implement this before or after taproot channels?

On the eclair side, we will implement this soon, much before taproot channels, this way we can pave the road for deprecation of the older closing protocols.