Lightning Specification Meeting 2024/03/25

[t-bast]

The meeting will take place on Monday 2024/03/25 at 7pm UTC (5:30am Adelaide time) on Libera Chat IRC #lightning-dev. It is open to the public.

⚠️ Some countries are switching to DST in the coming weeks, be careful with the meeting time!

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.

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Simplified mutual close option_simple_close (features 60/61) #1096
• Liquidity ads option_will_fund: liquidity ads #878 Advertise liquidity ads rates #1145
• Allow sciddir_or_pubkey for every hop Compact representation for node id #1138
• Async payments Support async payments in BOLT 12 #1149
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments 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
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071 blip-0004: experimental endorsement signaling in update_add_htlc blips#27
• Offers Offers #798
• DNS-based offers Define a mechanism for looking up an offer from a user/domain pair #1136
• 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

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.

• Zero reserve Add option_zero_reserve (FEATURE 64/65) #1140 (follow-up on bolt2: relax channel_reserve_satoshis requirements #1133 to include a feature bit)
• 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
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

rbf coop close RBF:

• question of if the sequence should be allowed to vary?
  • may confuse implementations, as before the sequence on coop close was static (non rbf)
  • also if the same value, then things are uniform everywhere else
• options:
  • leave the field, restrict value
  • don't change
  • remove the field, repurpose bytes
• proposal:
  • change the fields to: channel id, fees, lock time

liquidity adds:

• ppl moving forward w/ version w/o any enforcement at all
• current version as a funding weight:
  • if you don't know the amt, or the coin distribution you have, then you can't predict the fees ahead of time, as the current proposal has the funder overpay on fees slightly
  • how to set the value?
    • if you set one funding weight for all the amts, you'll pay for all the on chain fees
    • or you need to make sure that your UTXO set matches the amt you're offering
    • or do fixed amt ads
      • could also do ranges as well
  • add more to the init message?
• final negotiation upon connection:
  • uses extra TLVS to negotiate the final details of the proposal
  • node ann: advertises ranges, you pay X for Y BTC
  • init: you connect and ask for a specific amt, then you answer back with the specific amt, I reply with the node ann

onion messaging scid+node key look up:

• can help save space, but also for nodes w/o a full channel graph
• mainly for the entrypoint of the graph

onion messaging paper:

• from FC: https://fc24.ifca.ai/preproceedings/104.pdf
• tackles problem of DoS in onion messages

async payments:

• Support async payments in BOLT 12 #1149
• if receiver is offline,

taproot chans:

• eclair continuing interop, making more progress, able to open channels
• @Roasbeef to update the taproot PR to add the nonce information

gossip 1.5:

• splitting disable bit into 3 bits? cc @ellemouton
  • chan perm gone (closed)
  • chan disabled peer gone (cannot go either direction)
  • chan disabled unidirectional
    * can split the current bit vector, or otherwise redefine it to implement the above
  • also room to have the splice incoming bit as well
  • generally part of nodes sending out an update on channel close

peer backup:

• lnd has PR towards now, nearly done, then can start on interop

stfu:

• active work to add the message to un-sftu a PR

trampoline:

• rn needs recipient supporting trampoline, with blinded paths, only requires introduction point supporting it
• if this is the case, then maybe makes sense to only support the blinded paths version

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#463, recording borked out a bit so it's partial.