Lightning Specification Meeting 2024/08/12

[t-bast]

The meeting will take place on Monday 2024/08/12 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.

• Clarify route blinding spec Clarify onions part 2: a bit deeper rework #1182
• gossip_status BOLT 7: gossip_status (feature 66/67) #1186
• Bolt 12 contacts / mutual message auth: https://delvingbitcoin.org/t/bolt-12-trusted-contacts/1046
• Offers Offers #798
• Channel jamming draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Liquidity ads option_will_fund: liquidity ads #878 Extensible Liquidity Ads #1153
• Splicing Splice draft (feature 62/63) #863 Channel Splicing (feature 62/63) #1160
• Async payments Support async payments in BOLT 12 #1149
• Dynamic Commitments Extension/dynamic commitments #1117 vs Upgrade on Reestablish BOLT 2: upgrade protocol on reestablish #868
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Attributable errors Attributable errors (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.

• Simplified mutual close option_simple_close (features 60/61) #1096
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• 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]

bolt4 re-work:

• has 2 ACKs, last call for review
• bolt 12 PR then rebased after that, goal to finish up and start to get merged in

gossip status:

• feedback that can just do more precise gossip queries in place
• can be used to just short circuit to syncing all state
• effectively a graph status message, can use to determine the size of the graph the other peer knows
• impl wise can just send it out after init
  • should we include in init or even ping/pong?
  • or is it a bad idea to do more frequently
• minisketch:
  • bitcoind just cares about deltas, not globally in sync?
  • we want minisketch on everything?
    • we have 3 buckets, want to figure out how to package
    • 64 bits is ideally, like scid, but want to have other information there
    • some additional considerations for using block heights:
      • ppl will be advertising block heights in the past w/ gossip 2.0
      • so do need global sync after all?
  • other differences between our use case, and what Bitcoin Core has in mind

gossip weirdness in the network:

• some lnd nodes getting spent channel announcements, may be related to CLN issue re hash tables
• some nodes getting invalid signature checks for channel update announcements

bolt12 contact list:

• delving post exploring the design space somewhat
• comments from reviewers re if we should even start to train users to recognize something like this
• what's the purpose?
  • we have payer ID can that be re-used?
  • is sort of what's being proposed, but instead we derive based on contract
  • so you have a mapping from payer key to contacts, allows for per dest+send public key to be dervied
• potentially wrap the contract ID wrapped in the handshake
  • rolled into the existing flow, but wouldn't be mutual
  • chicken and egg issue re getting to mutual auth?
  • potential flow:
    • scan offer -> "do you want to add this person to contacts?"
    • sender clicks yes -> include contact ID in flow -> receiver prompted to remember that person
    • receiver click yes -> sends contact ID

offers:

• plan to rebase PR after the onion message stuff lands

channel jamming:

• bLIP merged
• eclair + lnd code works to allow forwarding it
• eclair working on reputation code, and setting the endorsements values, etc, etc

taproot chans:

• to move back to gossip stuff soon, blinded path send+recv

rbf coop:

• eclair and lnd close to interop

splicing + liquidity ads:

• waiting on review
• eclair PR for liquidity ads ready to test
• CLN refreshing impl based on current active PR, inching towards more interop w/ eclair

async payments:

• t-bast added a commit to trampoline PR that adds how it interacts w/ blinded payments
  • wanting to get feedback on how updated trampoline interacts w/ async payments as a whole

dyn commits:

• need to be divided into two pieces: param changes, and funding output conversions
• lnd grinding through PRs to refactor stuff, get in stfu, and work on implementing the param changes