Lightning Specification Meeting 2023/04/24

[Roasbeef]

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

• Correct final CLTV for blinded paths: Correct final_cltv handling in blinded paths #1066
• 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
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851 (Store state when sending commitment_signed niftynei/lightning-rfc#13 and Use signed amounts in RBF messages niftynei/lightning-rfc#15)
• Splicing Splice draft (feature 62/63) #863
• Fat errors Attributable errors (feature 36/37) #1044
• Clarify channel_reestablish requirements Clarify channel_reestablish requirements #1049 or Rework channel_reestablish requirements #1051
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881

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
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016
• ~Update static channel parameters zzz-extension-bolt: dynamic commitments #1026
• 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

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
• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Simplified commitment Feature 106/107: option_simplified_update. #867
• 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)

[Roasbeef]

blinded paths final CLTV delta:

• Don't have a final CLTV delta, as you only have the full blinded path
  • Since the receiver is the only that constructs the latter part of the route
• If you add any random values, then have to tell the recipient
• Max cltv expiry was meant to be in the invoice, but seems to not actually be there anymore
  • Goal to catch up the spec to implementations cc @t-bast @rustyrussell

onion messaging:

• test vectors updated, now rebased on top of blinded paths

offers:

• now also rebased, implementations converging
• LDK a little bit away from interop testing, need to finalize the data structures, and also need the ability to generate blinded paths

max_dust_htlc_exposure_msat addition:

• need review from other implementations, acinq ACKd

taproot:

• anchor output, tradeoffs re allowing 3rd parties to sweep
  • the internal key they need to make a control block may not always be revealed
  • modifying the to_local to have the revocation path in the script path
  • before: can be swept after 16 block
  • now: can be swept after 16 blocks, and the local party has swept
  • possible to add more information in the gossip to make it always sweepable
  • another path:
    • make the witness slightly larger, by moving the revocation
• which key is used for the to_remote party's internal output
  • realized that nice for back up + recovery

taproot chans:

• implications of block height based rate limiting
  • gossip query implications
  • rate limiting re burst
• TLV everywhere or not
  • can be useful for revealing all the information w.r.t bitcoin script outputs
• how much should be bound in the output:
  • how much the output script be bound?
  • how much the value should be bound?

attributable errors:

• is this compatible with blinded paths? does it require any additional changes to be compose?
• shouldn't be a problem?
  • as just dropped from the introduction points, as then you want to make sure that you don't unnecessarily penalize for dropping the hmacs

peer channel backups:

• CLN had an intern do node uploads for backup data
• old eclair version as well
• open work here to see if both can be combined or not

inbound fees:

• lnd looking at including in upcoming release
• implications re negative fees and if one can rely on other peers to send channel_updates
• other peer level proposal updated
  • now factors in a time to wait before the peer starts to properly enforce the fee update

[carlaKC]

transcript: bitcointranscripts/bitcointranscripts#261