Lightning Specification Meeting 2023/10/23

[t-bast]

The meeting will take place on Monday 2023/10/23 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 / Seeking Review

This section contains changes that have been opened or updated recently and need feedback from the meeting participants.

• Clarify offered and negotiated features BOLT 1: define what offered and negotiated mean. #1109
• Harmonize max cltv_expiry across implementations BOLT4: Specify max HTLC nLocktime for expiry_too_far #1086
• Simplified mutual close option_simple_close (features 60/61) #1096
• Spec clean-up Clean up: remove two unused features, assume four more #1092
• 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 vs Upgrade on reestablish BOLT 2: upgrade protocol on reestablish #868
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Attributable errors Attributable failures (feature 36/37) #1044
• 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

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: 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 or Peer storage for nodes to distribute small encrypted blobs. #1110
• 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)

[t-bast]

We're entering the daylight savings time changes mess, I'm not 100% sure I put the right time, be ready for last minute changes!

[vincenzopalazzo]

We're entering the daylight savings time changes mess, I'm not 100% sure I put the right time, be ready for last minute changes!

Most people are using my calendar.

For people that stay in CEST timezone, the meeting will be 1h before the last one

The lightning network meeting is in UTC timezone and not in the Adelaide one (as the core lightning one) so this change should be a little bit less messy

My calendar says that the lightning network meeting timezone should be in Central Australia Time/Adelaide timezone, so I believe it

[t-bast]

Re-purposing this issue for today's meeting since the last one didn't happen.

[Roasbeef]

feature bit checks:

• intent to make more lenient on the sender side of things: BOLT 1: define what offered and negotiated mean. #1109

new co-op close:

• want to leave off last commit where we remove
• lnd implements the RBF signalling, but plans to upgrade w/ the new feature bit
  • staging bit just signals RBF, final version will also assume the new co-op close
• moves to get more introp, eclair ready ready for interop

cleaning up features w/ required bit
* lnd prepped to add in lnd 0.18
* eclair has in master branch, to go out this week or the next

offers:

• LDK next release will have a basic version, needs direct connect
• eclair ready to test scid encoding variant with other impls too

splicing:

• dusty still handling the PR rn
  • working on restart related nuances on the implementation side of things
  • according to t-bast a lot of cases re the restart stuff, based on TLVs in the chan reest message
• CLN continuing to test, running into some fun edge cases

dual funding cross compat

• need some final stuff, related to restarting that needs interactive-tx, one sides sends commit sig + tx sig
  • need to make sure able to finish the signing session
    * lisa working on final fixes here

taproot:

• splicing nonces for taproot chans, can use the same ordering
  • if don't want explicit ordering, then have the splice ordering of the transactions, order the nonces
  • explicit: would map splice tx to nonces
• miniscript analysis run: extension-bolt: simple taproot channels (feature 80/81) #995 (comment)
  • need to double check the scripts side by side, looses a byte here n there

gossip 1.5:

• thinking about how to support the backwards compat
  • segwit v0 channels to announce the new gossip 1.75 messages, chanupd2, ann2
  • do we also support the queries with block timestamp and block height
    • possible to map one to another, dev wisdom says harder in practice w/ edge cases n stuff
  • also path to just do minisketch instead, so then all block heights

attributable errors:

• ready to do interop w/ joost

zero chan reserve:

• want to be set to zero, to allow setting it
• even if set to zero, then you still need to fee to pay for the tx
  • not zero, but instead it's min to pay for fees (as initiator?)
• how is this diff from zero conf?
  • zero conf is transient, this is for the lifetime of the channel
• LDK allows the counterparty to set zero, but they don't set it themselves
• splicing overlap
  • as you add funds, need to also put in 1% for each time you add additional funds
• deployment path: use a feature bit, means that both sides get zero reserve

[carlaKC]

transcript: bitcointranscripts/bitcointranscripts#293