Lightning Specification Meeting 2023/12/04

[t-bast]

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

Special topics

• Mailing list host ending support in 2023

Recently Updated Proposals / Seeking Review

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

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Liquidity ads option_will_fund: liquidity ads #878
• 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
• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• 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 Extension/dynamic commitments #1117 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 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 or Peer storage for nodes to distribute small encrypted blobs. #1110

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

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

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• 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
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

dual funding + splicing pinning concerns:

• concerns around pinning due to funky inputs in the funding transaction, or nesting transactions off the change
• general issue whenever offering inputs into a multi-party transaction you have this issue:
  • they can try to pin or delay confirmation with a large witness
  • or nest other transactions from the funding+splicing transaction
• workarounds:
  • have them send tx signatures first, then means they can broadcast first
    • can be done in the form of a new TLV that restricts this, may make batching harder
  • restrict the input types to: p2wkh, and p2tr
    • for multi-sig, would need to create set templates
    • (roasbeef's opinion): this is how you resolve it 100%, at least from the input standpoint

liquidity ads:

• discussion on the mailing list about capital being locked up
  • main issue:
    • have 10k sats in a channel, someone puts in 10 BTC, I route that, the 10 BTC is now locked for the duration
      • only applies to dual funder case, for single, only one party puts funds in
  • other matters:
    • wanting to enable very long leases like 1 year, but then not lock the seller into the full duration?
      • really depends on the pricing and preference model
    • if you want to extend the lease, then assuming dyn commits, can negotiate it off chain to extend

simple close:

• main change is to specify the nsequence, removed the old stuff (in new commit still)
• lnd will working on impl, working on getting up the PR

compulsory bits:

• CLN+lnd both working to flip it on in release early next year

stfu:

• keagan working on some changes to ensure that no matter what message ordering happens, the channel can always be stopped
  • according t-bast: scenario doesn't necessarily apply?
  • may be some other edge cases within the protocol flow, but can be solved in practice with just timeout values?

mailing list:

• votes:
  • discourse: * * *
  • traditional mailing list: * *
  • groups.io: * *