Lightning Specification Meeting 2024/04/22

[t-bast]

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

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Constant size failure onion decryption BOLT04: Add rationale for constant error decryption. #1154
• Notation for math content BOLT-04: use underscores in place of parens for blinded paths notation #1151
• Liquidity ads option_will_fund: liquidity ads #878 Advertise liquidity ads rates #1145 Extensible Liquidity Ads #1153
• Async payments Support async payments in BOLT 12 #1149
• 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 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)

[t-bast]

I'll do my best, but I'm not sure I'll be there in time for this meeting. In case I can't attend, here are some topics I'm waiting for feedback on:

• I think it's time to finalize Clean up: remove two unused features, assume four more #1092, and I've added a commit containing some clean-up (see Clean up: remove two unused features, assume four more #1092 (review))
• I've posted a new design for liquidity ads in Extensible Liquidity Ads #1153 that is more open to extension, and I believe would work great to unify LSP specs with the BOLTs and bLIPs, I'm chasing some concept ACK on this (@niftynei)
• In order to ship some prototype Bolt 12 implementation, we'd like to get rid of a requirement that unnecessarily duplicates the node key: Offers #798 (comment) (@rustyrussell)
• it would be great to make progress on taproot gossip, we've all signaled willingness to ship it whenever possible

[Roasbeef]

feature bit clean up:

• lnd will implement as is in 0.18, the rest have as well
• no blockers to landing, ppl should add their final approvals

constant sized decryption:

• does everyone actually do it?
  • seems so
• PR also updates the 20 hop value to 27 (can be considered an independent bug fix)
• perhaps we should just make the section more generic?
  • so advise randomization between payment retries, remove the prescriptive text rn re the exact method
  • other areas:
    • fuzz latency responding to pings

LaTeX for blinded paths:

• merged!
• BOLT-04: use underscores in place of parens for blinded paths notation #1151

unified liquidity ads:

• new PR, more extensible
• looking for concept ACK

async payments:

• still working on LDK updates, have some updates to feature bits, etc

stfu:

• keagan submitted a PR to rusty's branch attempting to add an explicit resume
  • PR: bolt2: add go_on to quiescence spec rustyrussell/lightning-rfc#14
• t-bast has replied to, fielding comments, now

splicing + dyn commits:

• key distinction re funding output channel updates:
  • always broadcast the splicing/kick off
  • keep it off chain as long as possible
• dyn commits as specified seeks to decouple negotiation from execution
  • can update dust limit etc w/o needing to change a funding output

taproot gossip + channels:

• eclair working on interop w/ channels
• rusty left some initial comments based on the current revision: extension-bolt: taproot gossip (features 32/33) #1059 (comment)

peer backup:

• impls underway
• spec PR getting some review now

channel jamming:

• was a hackathon at the MIT bitcoin conf
  • had ppl launch attacks, not totally broken, but have some new insight from it
  • will be a delving post summarizing

offers:

• idea to make the node ID implicit, can make the QR code smaller
  • should it be done before or after we merge it in?
  • has been implemented in Phoenix, want to have the default, small change
    • for certain apps, won't change for the foreseeable future
  • may miss the LDK release deadline
• can implement sending to it vs also understanding receiving to it
• state of CLN implementation:
  • a bit behind the spec
  • shooting to update it for next CLN release, sometime in May
• what does minimal interop here look like?
  • multi-hop fetch? dummy hops? direct connect?
• expiry height issue to be addressed

DNS based offers:

• waiting for more feedback

[t-bast]

idea to make the node ID implicit, can make the QR code smaller
should it be done before or after we merge it in?

It must absolutely be done before merging, otherwise old readers won't know how to read offers that don't include this offer_node_id, it will require a mandatory feature bit, which is really wasteful. From the reader's point of view it's a trivial change, I think it belongs to the MVP.

[TheBlueMatt]

It must absolutely be done before merging, otherwise old readers won't know how to read offers that don't include this offer_node_id

I mean we have to draw the line somewhere, and its not like we won't eventually add new features to the offer...

it will require a mandatory feature bit, which is really wasteful.

It does not - old senders will simply fail to read the QR, same behavior whether its a feature bit or not :).

From the reader's point of view it's a trivial change, I think it belongs to the MVP.

Fair, but sadly LDK is gonna ship a new release without this and we anticipate pushing some of our larger users to integrate BOLT12 using this release. Of course that doesn't mean all that much, but it may mean that people start supporting BOLT12-send in production without this feature for a month or three.

[t-bast]

It does not - old senders will simply fail to read the QR, same behavior whether its a feature bit or not :).

Right, but that's really not the UX we want to have for the first wave of Bolt 12 adopters! It would be really sad to have cross-compatibility issues like those right from the start.

Fair, but sadly LDK is gonna ship a new release without this and we anticipate pushing some of our larger users to integrate BOLT12 using this release. Of course that doesn't mean all that much, but it may mean that people start supporting BOLT12-send in production without this feature for a month or three.

That means omitting the offer_node_id won't make it for the LDK release, but that doesn't mean it shouldn't make it for the initial spec release, right? Especially since cross-compat tests haven't been made yet, and will likely require an iteration cycle with code changes (since we want two interoperable implementations before merging the spec PR). I'd consider that the first implementation releases with Bolt 12 support should be experimental and allow us to test cross-compat, and we'll need at least one more release cycle to drop that experimental flag and freeze the spec. IMO this change should make it into the spec during that cycle :)

[TheBlueMatt]

Right, but that's really not the UX we want to have for the first wave of Bolt 12 adopters! It would be really sad to have cross-compatibility issues like those right from the start.

Sure, my point was more about the long-term not the immediate-term. Sadly we have to draw the line somewhere and this came up late in our "okay, BOLT12 is usable now" release and didn't get to implementation. @jkczyz did indicate he'd look at it today so maybe we can still slip it in, but no promises.

That means omitting the offer_node_id won't make it for the LDK release, but that doesn't mean it shouldn't make it for the initial spec release, right?

I mean sure, I don't care too much about the spec, I care a bit more about the UX in the wild, but whether its "in the spec for v0" or not seems kinda irrelevant to me - it doesn't need a feature bit so we can merge it before or after BOLT 12.

Especially since cross-compat tests haven't been made yet, and will likely require an iteration cycle with code changes (since we want two interoperable implementations before merging the spec PR)

This isn't entirely true. LNDK has things working with eclair and we've made some progress with CLN just waiting for some blinded path "who connects" compat changes in CLN. At this point, we're ready for cross-compat tests, and as far as I'm aware eclair is too. That means, as far as I'm concerned, we're ready to go here.

I'd consider that the first implementation releases with Bolt 12 support should be experimental and allow us to test cross-compat, and we'll need at least one more release cycle to drop that experimental flag and freeze the spec. IMO this change should make it into the spec during that cycle :)

Yes, that was our release two releases prior, we're not past that point at least on the LDK end and hoping to do cross-compat tests with eclair directly (ie not from LNDK) in the coming week or two :)

[t-bast]

@jkczyz did indicate he'd look at it today so maybe we can still slip it in, but no promises.

If that can be done for the reader side, that would be great! Otherwise that will be for the next release then.

This isn't entirely true. LNDK has things working with eclair and we've made some progress with CLN just waiting for some blinded path "who connects" compat changes in CLN. At this point, we're ready for cross-compat tests, and as far as I'm aware eclair is too. That means, as far as I'm concerned, we're ready to go here.

I didn't know you were at that point, is there a place where we can track cross-compat tests (which would allow multiple people to contribute to the testing effort as well and report on the results)?

On the eclair side, we still have a few changes we'd like to make (improvements discovered when implementing the wallet side of things), we should be ready as well in a couple of weeks. Looking forward to making those tests!

[TheBlueMatt]

I didn't know you were at that point, is there a place where we can track cross-compat tests (which would allow multiple people to contribute to the testing effort as well and report on the results)?

Uhh, I'm not aware of one. @orbitalturtle or @carlaKC may have one somewhere for the LNDK end. I've only personally tried (and failed) to pay CLN, but would like to test eclair next week.

[orbitalturtle]

Cool yes! I've sort of been informally tracking issues I've or others have had here: lndk-org/lndk#93 Feel free to add things... or it could certainly be absorbed somewhere more appropriate

Since Polar allows importing custom networks, I've been posting some Polar zip files and configurations I've set up here, to make manual regtest testing somewhat easier. I think most of the instructions are outdated RN, but if anyone finds it helpful, happy to update: https://github.com/orbitalturtle/offer-testing-tools/

I've only personally tried (and failed) to pay CLN, but would like to test eclair next week.

If helpful for that, I wrote up some instructions on paying an eclair offer via the tipping plugin, since that's where we've had success paying with LNDK so far :) https://github.com/lndk-org/lndk/blob/master/docs/test_pay_offer.md

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#477