Lightning Specification Meeting 2024/07/29

[t-bast]

The meeting will take place on Monday 2024/07/29 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
• Offers Offers #798
• Bolt 12 contacts / mutual message auth (Add blip-0031, a protocol for mutual message exchange blips#31 and blip-0042: Bolt 12 Contacts blips#42)
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• 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
• Liquidity ads option_will_fund: liquidity ads #878 Extensible Liquidity Ads #1153
• Async payments Support async payments in BOLT 12 #1149
• Splicing Splice draft (feature 62/63) #863 Channel Splicing (feature 62/63) #1160
• 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
• DNS-based offers Define a mechanism for looking up an offer from a user/domain pair #1136
• BIP 353 name in offers Include BIP 353 name info in invoice_requests #1180
• 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.

• 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]

blinded paths for payments:

• use blinded paths before the introduction point?
  • do we gain anything by adding one from the sender?
  • part of the onion rework: Clarify onions part 2: a bit deeper rework #1182 (comment)
• how do ppl handle dummy paths?
  • when you add dummy hops, do you also add extra fees in addition to CLTV values?
    • fees may make it look more legit, but at the cost of actually increasing fees for the sender
    • the sender can eat all the fees themselves?
    • are there other probing vectors w/ zero fees?
  • what values do people use?
    • lnd today: all the hops are padded out to the same value
    • CLN today: wanting to settle on a value of 3, still a fixme

gossip status:

• you tell a peer your stats, and then they decide just to flood you with everything
  • inspired to want to fast catch up a node that was offline for a long time
• reintroducing the old initial gossip dump, but with more context
• some impls already ask for all the gossip on reconnect
• zooming out:
  • have all found weird issues with gossip, haven't cohesively tracked them all down
  • should we add more band-aides vs going for the bigger re-work?

offers:

• CLN implementation caught up, others should be able to test against the master branch
• invoice errors:
  • expected only from invoice requests, or invoices as well?
  • should be able to send an error in response to an invoice
    • you can't reply if you don't send a reply path though
    • or you can just send via the invoice request
      • unless impls have stricter logic re how you can send messages and with which paths
      • stateless approach would allow though
• recurrent stuff moved over into the set of experimental ranges

bolt 12 contact list:

• wanting to have a feature like a contact list, shows that your friends paid you again
• before:
  • used the payer key in the offer
  • forces linking to a single offer, or having to re-use a payment key for future offers
• should we do something else?
  • can derive some "contact key", bootstrapped somehow, used to allow linking
    • but then need a way to distribute the keys, in the URI? or BIP 353?
    • can then include in the encrypted payment data, so then sender doesn't necessarily see the correlation
• does the issuer field allow us to handle this?
  • issuer field, then some comment?
    * key exchange protocol when you first pay
  • also some overlap with nostr, working on key distribution web-of-trust-y thing
    * what are the ideal properties?
  • recipient can only see someone paid when you're mutually in the contact list of the other:
    • A learns only if both A and B are in each other's contact list
  • LDK has transient payer key by default, Eclair evaluating hybrid approach

taproot:

• eclair working on the splicing side of things, re extra nonces

taproot gossip:

• lnd working on getting back to, working on blinded paths stuff

channel jamming:

• been some recent discussion re channel jamming
• down to bike shedding on values for the bLIP
  • is a binary value enough, or should we use some integer range?
  • simple version: 0 is unendorsed -- up to you re interpretation
• is the extra level of granularity actually useful?
  • could use the 0-7 as a percentage of success?
    • could use some historical data, but requires existing payment attempts through the node?
  • would be useful to have some numbers re the ranges:
    • code is almost ready, blocked on deciding what to do if not running reputation code
      * proposal: only forward on endorsed if fully endorsed, otherwise drop to 0

splicing:

• Eclair has a PR to start using official values, so can run interop with

trampoline:

• more work re how to combine trampoline and blinded paths, t-bast posted some commits

liquidity adds:

• updated spec based on past comments, ready to review

nLightning:

• new impl on the block: https://github.com/ipms-io/nlightning
• doing BOLT 2 and 3
• finished: BOLT 8, 9, 10, 11
• started to BOLT 11 as well
• ideal path to a new impl?
  • wanted to go from 1 to 11, realized need to take a diff approach