Roasbeef
commented
1 month ago mpp in blinded paths:
- how do ppl handle it today?
- impls:
- lnd: adds the blinded paths as hop hints of sort
- ldk: similar hop hint generalization
- eclair: similar hop hint generalization
- CLN: super simple, just appends the onion
- when you get an error from inside the path, do you try to split or not?
- do you just split inside the same blinded path?
- eclair has a trick where they add the blinded path multiple times
- seems to work ok-ish, so they can have more vectors to split based off
- eclair has a trick where they add the blinded path multiple times
- impls:
channel udpate w/ max HTLC:
- does lnd allow channel updates that don't have it set?
- observed with peering w/ certain lnd nodes
revamping bolt 4 spec:
- seeks to not change anything
- tightens up all the language, better requirements, etc
- touches mainly blinded paths and general onion processing
- next up would be to revamp the generation portion:
- when we get here, can also add some of @ellemouton's diagrams from: https://ellemouton.com/posts/sphinx/
offers interop:
- phoenix and LDK doing a lot of interop rn
- going well, exposed bugs that are being patched
- also want to test all the failure cases:
- may be a bit more indirect, but worth it to make sure that everyone handles in the same
- CLN has some new test vectors, generated during rewrite
- exposed some other edge cases w/ the DNSSEC resolution, more robust now
BIP 354 DNS operations:
- wild card method for hosted providers: https://github.com/lightning/bolts/pull/1180
- some using route 53 AWS API rn to handle automation for the multi-user case
- DNS servers generally pretty lightweight
- ₿ prefix on addrs
- lost of prior discussion
- wanting to be compat and support downgrade, etc w/ LN-URL
- naming collisions possible, etc
- spec tries find a good middle ground
- overlap w/ email addresses, etc
- composes well with silent addresses
- whole new BIP to replace BIP 21, if you add a new addr format, put it in the query params
- ppl wanting to add sending support
- some are PSBT based, waiting on: https://delvingbitcoin.org/t/bip352-psbt-support/877
- most important to be able to pay to them
taproot chans:
- eclair has some draft PRs up
taproot gossip:
- elle incorporated rusty's latest diff
- ppl working on reloading context
- seemingly some propagation issues in gossip today as well
- working on adding extensions w/ splicing re nonces, etc
channel jamming:
- nothing blocking really, waiting to her from thomas on the bLIP
- discussion directly on the bLIP
async payments:
- landing PRs in LDK
- t-bast working on the trampoline to blinded paths, and the other way around
splicing:
- eclair wanting to put up a PR using the official values for the TLV numbers
- slight divergence in impl
dyn commits:
- splitting up the kick off upgrade part from the rest
- to be distinct documents
- may use the same negotiation mechanism
liquidity ads saga:
- few questions t-bast has
- really useful is how to pay the fee, can be extended, can pay in interactive tx, or deduct fees from diff HTLCs, etc
- subscription fee, etc
- how do we also specify the lease duration, etc
- script enforce or just advisory?
- script enforce is nice in theory, but gets hairy once you factor in splicing and routing, etc
- re lease duration:
- just make it fixed?
- can always partition the buckets later if needed
- really useful is how to pay the fee, can be extended, can pay in interactive tx, or deduct fees from diff HTLCs, etc
peer storage:
- spec PR pretty much done
- CLN impl set, working on expanding the set of capabilities
The meeting will take place on Monday 2024/07/15 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.
max_cltv_expiry#1176channel_reestablishrequirements #1049 or #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.
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.
channel_reestablish#934~Long Term Updates
This section contains long-term changes that need review, but require a substantial implementation effort.