Skip to content

Meeting Notes 2024 07 08

Elias Rohrer edited this page Jul 8, 2024 · 1 revision

LDK Releases

LDK Node Release

Language bindings

Matt might try to get a jump on 124 lang bindings so that can go quick but still a few weeks away

Developer support

Fee estimation docs improvements incoming

Feature progress

  • Async payments
  • RGS
    • Client side for V2 format landed in LDK and will be in 124
    • Server side also landed
    • Some add’l features trying to add for the server that should be in soon, then will tag a version for the server
    • For v2 gossip, 124 users will have to explicitly opt into that with a new path
  • VSS
    • For ldk-node integration, waiting on fallible event handling PR landing in LDK. that would be the first prereq to ensure we don’t arbitrarily panic when failing to persist events
      • Willem: getting PR ready for vss rust client, then can move on to LDK Node integration
    • Tnull: integration is done, and have an old WIP with language bindings integration
    • Dual funding
    • First PR that enables DF but not allow ldk users to add their own funds to the channel for inbound chans might land for 124, but no material features to use there yet
    • Good progress towards 125 having solid DF support
  • Splicing

Open Q&A

  • Shaavan: 3087 review beg
  • Slanesuke: waiting on ldk update to handle bolt 12 events for https://github.com/lightningdevkit/ldk-node/pull/302
    • Some decisions to be made there about whether ldk-node should try on-chain if offchain fails
    • Should optimistically choose bolt 12
    • cc https://github.com/lightningdevkit/rust-lightning/issues/3159
    • Tnull: need to figure out whether falling back from b12 to b11 is feasible, from qr code size perspective and also wallet support perspective
    • Matt: on the size q, it’ll depend if we have an lsp it might be that b11 is too big and can’t fit b12. In some cases wallets don’t want to support onchain fallback. If that’s the case and you’re a public node who’s willing to use b11, could include b12 as well bc b11 will be pretty small. Q is, what happens if it’s too big? For api simplicity, we just do b11 for now, likely. But maybe we also want a separate api for b12 bc it’s reusable.
Clone this wiki locally