1 Meeting Notes 2024 11 11

Elias Rohrer edited this page 2024-11-11 19:32:54 +01:00

Unescape Escape

Table of Contents

• LDK Releases
• LDK Node Release
• Language bindings
• Developer support
• Feature progress

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

LDK Releases

• 0.1 (https://github.com/lightningdevkit/rust-lightning/milestone/1)
  • Chugging along
  • Hoping to get this out by the end of the year but a lot of work left to get there
  • Async persistence is the main blocker here
  • Probably won’t have splicing support but hopefully it will come shortly thereafter
• 0.1.1 (https://github.com/lightningdevkit/rust-lightning/milestone/17)
• 0.2 (https://github.com/lightningdevkit/rust-lightning/milestone/2)

LDK Node Release

• 0.5 (https://github.com/lightningdevkit/ldk-node/milestone/5)
  • Making progress here
  • Landed some smaller refactors to allow draining the on-chain wallet while maintaining the anchor reserves, stuff like that
  • Making first steps for larger refactor of logging infrastructure
  • See milestone
  • Depending on how timelines play out, 0.5 should come out after LDK 0.1 so LDK Node can rely on some upstream changes
  • Lexe: in the issue about 0 counterparty channel reserve, we want users to be able to send the full balance. Seems like in anchors world, you still need a reserve. Can we still send the full balance over lightning, or does it need to sweep to another onchain address?
    • tnull: i think so. Dropping the balance in general depends how much trust you have in your counterparty. In the usual client<>LSP model, with 0-conf, there is trust established. Arguably could also drop the anchor reserves in this case.
    • Note: anchor balance is on-chain reserve
    • LDK Node has 3 modes: 1: don’t ever bump anchor outputs, totally trust counterparty. 2: we don’t maintain a reserve, but if we do have funds we would use them to try to spend the anchor. 3: trustless model where you maintain on-chain reserve to close the channel.
    • Lexe: lots of wallets want to move towards a unified balance experience, vs keeping an unspendable reserve, and trying to eliminate the distinction between onchain and offchain funds. Doesn’t seem possible without trusted model where user doesn’t have anchor bumping reserve?
    • tnull: you could start with 0 anchor reserve, and then notify the user later to “insert coin now” when needed. Note that there was recent discussion in the spec meeting about 0 reserve.

Language bindings

Developer support

• Conor: probing docs are open still, so reviewing that
• Recent conferences had LDK Node workshops
• Plan to have more templates for people to hack on in the future to give them something to go on

Feature progress

• Async payments
• RGS
• VSS
  • Optimizations under way
  • Batching in postgres implementation
  • Postgres implementation is complete overall, though.
• Dual funding
  • We have accepting inbound DF channels almost landable
• Splicing is blocked on this
  • jkczyz to do some follow-up work on DF
  • Optout is working on splicing now, doing some refactors right now
• Splicing
• Open Q&A
• Would it ever be possible to have full concurrency implemented, eg LDK feeds events to some consumer/trait directly and we uphold some contract like “do our best to persist the event, and handle it after that”?
  • Matt: LDK needs to know when the event has been persisted. Technically LDK doesn’t have to persist the events, you’ll just get FCs on startup.
  • We do need to know when the events are durably handled, and an event will not be lost (either it was already processed and the result was persisted or the event itself was persisted).
  • If a payment is claimed, we need to know that the user has persisted the preimage and LDK is safe to delete it
  • But not sure what that has to do with concurrency – some events have logical ordering requirements. Other than that, the async event handler can be fully concurrent.
  • Tnull: concurrent event handling is an interesting issue, but could be complicated. In Lexe case, this is an orthogonal issue to what you actually want to solve, which is HTLC interception. I linked the relevant issue here on the concurrent event handling issue.