-
Notifications
You must be signed in to change notification settings - Fork 492
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
Comments
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:
|
feature bit clean up:
constant sized decryption:
LaTeX for blinded paths: unified liquidity ads:
async payments:
stfu:
splicing + dyn commits:
taproot gossip + channels:
peer backup:
channel jamming:
offers:
DNS based offers:
|
It must absolutely be done before merging, otherwise old readers won't know how to read offers that don't include this |
I mean we have to draw the line somewhere, and its not like we won't eventually add new features to the offer...
It does not - old senders will simply fail to read the QR, same behavior whether its a feature bit or not :).
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. |
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.
That means omitting the |
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.
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.
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.
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 :) |
If that can be done for the reader side, that would be great! Otherwise that will be for the next release then.
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! |
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. |
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/
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 |
Transcript: bitcointranscripts/bitcointranscripts#477 |
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.
Attributable errors Attributable errors (feature 36/37) #1044Clarifychannel_reestablish
requirements Clarifychannel_reestablish
requirements #1049 or Reworkchannel_reestablish
requirements #1051Stale 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#22Waiting 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) #1096Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836Zero reserve Addoption_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 afterchannel_reestablish
Nodes shouldn't publish their commitment when receiving outdatedchannel_reestablish
#934Long 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. #867lnprototest (https://github.com/rustyrussell/lnprototest)The text was updated successfully, but these errors were encountered: