Lightning Specification Meeting 2023/07/31

[t-bast]

The meeting will take place on Monday 2023/07/31 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.

• Simplified mutual close option_simple_close (features 60/61) #1096
• Clarify behavior when both optional and mandatory feature bits are set bol09: Specify behavior when a node specifies both optional and required features #1095
• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Correct final CLTV for blinded paths: Blinded Paths: clarify outgoing_cltv_value for final hop #1097 and Clarify final cltv expiry computation in route blinding #1069
• Harmonize max cltv_expiry across implementations BOLT4: Specify max HTLC nLocktime for expiry_too_far #1086
• Attributable errors Attributable errors (feature 36/37) #1044
• 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
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• 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
• 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.

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• 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
• Anonymous gossip
• lnprototest (https://github.com/rustyrussell/lnprototest)

[t-bast]

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

[jkczyz]

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

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