Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lightning Specification Meeting 2024/04/22 #1155

Closed
13 of 22 tasks
t-bast opened this issue Apr 18, 2024 · 10 comments
Closed
13 of 22 tasks

Lightning Specification Meeting 2024/04/22 #1155

t-bast opened this issue Apr 18, 2024 · 10 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented Apr 18, 2024

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.

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.

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.

Long Term Updates

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

@t-bast t-bast pinned this issue Apr 18, 2024
@t-bast
Copy link
Collaborator Author

t-bast commented Apr 18, 2024

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:

@Roasbeef
Copy link
Collaborator

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:

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:

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:

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
Copy link
Collaborator Author

t-bast commented Apr 23, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator Author

t-bast commented Apr 23, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator Author

t-bast commented Apr 23, 2024

@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
Copy link
Collaborator

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
Copy link

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

@t-bast t-bast unpinned this issue May 2, 2024
@t-bast t-bast closed this as completed May 2, 2024
@carlaKC
Copy link
Contributor

carlaKC commented May 13, 2024

Transcript: bitcointranscripts/bitcointranscripts#477

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants