Skip to content

Meeting Notes 2023 07 10

Jump to bottom
Elias Rohrer edited this page Jul 10, 2023 · 1 revision

Releases

  • 0.0.116 (https://github.com/lightningdevkit/rust-lightning/milestone/33)
    • There’s still a handful of things to review, everything’s open with PRs
    • Some nontrivial things to review
    • Hopefully will finish this week, might slip into the weekend
    • Would love to do another alpha on wednesday or so after we get a few more things landed, then we’ll need to do bindings and cut the release
    • Tony: we used the alpha in mutiny, need some mutex changes so running on the main branch since a few days ago. Upgrade path was easy.
  • 0.0.117 (https://github.com/lightningdevkit/rust-lightning/milestone/34)
    • A lot of async/BOLT 12 stuff
    • Matt: would love to make this a quicker release cycle
    • Async mostly landed in 116 with the intent to support people downgrading to 116 even if they’ve used async in 117
    • If we can get blinded paths in in a couple of weeks, we can cut 117. Don’t think we’d want to wait on anything else. A lot of stuff is open that is waiting on 117 as well.
  • 0.1 (https://github.com/lightningdevkit/rust-lightning/milestone/1)

Roadmap Progress

  • Developer support
  • Payment protocols
    • As mentioned, hoping to land the rest of BOLT 12 in 117
    • Jeff has a PR open, val and matt to review
    • Val: 4 PRs queued up to open for route blinding in the next few days, just finishing up error handling and tests
  • Language bindings
    • Matt: will try to do 116 binding before cutting the release for additional test coverage, not quite finished on it yet
  • Taproot support
    • Arik: most of you know Zman threw out a new proposal after the LN Summit re: have no nonces exchanged til close negotiation, bc those nonces are in support of unilateral closes which are comparatively rare, so will be fine to spend more money on having individual sigs as opposed to a schnorr aggregated musig2. But i am continuing to operate on the assumption that for the time being this is not going forward, though it prob will. Hoping to have an alt to 2289 up a bit later.
  • Anchor outputs
    • Current have a PR up fixing some stuff Elias found fixing stuff found via LDK Node integration.
    • Wilmer to do a livestream with Conor in ~2 weeks, rundown on a sample impl of anchors in LDK Sample. There will also be a blog post for anchors.
    • Users will have to opt in manually in the user config, which you can provide either globally to your node or per channel. And if you want to accept inbound, you’ll need to enable the manual acceptance mode in the config, and this is bc in anchors you want to uphold an onchain fee reserve for channel closes, and the manual acceptance hook gives you the chance to enforce that, otherwise you might accept a lot of channels without having the funds to back it up if they go on-chain. More details to come in the livestream.
    • Not default yet. That will probably happen in 2 releases or so.
    • There’s also the BumpEventHandler (a small wrapper around the wallet), which will simplify handling fee bumps. It gives LDK access to the UTXOs or the transaction itself.
  • LSP
    • JCantrell: LSPS0 is merged, some other project outside of c= has integrated it as well. At c= i have a branch ready with our JIT channels LSPS2 (ready for review), working thru some things there. An SoB student is working on LSPS1, the channel request flow.
    • Matt: i want to consider whether we should move those crates into the main rust-lightning repo. Not necessarily now, nice that they can move quicker for now. But once we get them more stabilized – that gives us the ability to include them in the same release process, they always get updated with CI, and potentially in the future included in our main LDK bindings generation. Thoughts?
    • Elias: in the long term, makes sense. Short term, i would wait bc the LSP spec itself is in flux. Would like to iron out the bumps/internal inconsistencies first. Also want to give it a shot to make it no-std.
  • VSS (Versioned Storage Service)
    • Added delete functionality
    • Trying to close out the client side PRs to complete phase 1.
    • Main work in phase 2 is to write local cache storage. Started work on this.
    • Re: ids – goal is that even if application doesn’t support versioning, they can still use VSS. client side impl keeps track. Let’s say they load the manager and have in memory state, they track the version #s.
    • Tony: had concerns about lack of versioning in channel manager. I think there’s enough workaround right now. But decoupling version #s from the lightning data itself is not ideal, IMO. I get why it is currently
    • Ben: if LDK had version counting, you could trust that way more rather than an arbitrary thing outside of it. But we have our version of it almost done so we’ll see how it goes
    • Matt: are y’all using vss protobufs directly?
    • Ben: no, we wrote our own http client
    • Matt: one of the things we were talking about for vss was a thin client wrapper that exposes a simpler/more native api rather than exposing protobufs directly. Seems like sth that should be done at that level. So in the future having some client lib that does the version counting, incrementing, etc is something we could consider.
    • Tony: ideally it’s encoded directly in manager/monitor
    • Matt: it’s not different. Because we would just use an incrementing counter, not different to do it at the storage layer vs LDK layer in terms of reliability/correctness. Part of the problem, having a version # in the LDK data is prone to confusion over what it represents, bc you can have 2 separate clients create two updates in multiplayer mode with the same id that are different updates, leads to confusion over what that api represents
    • Tony: point is, it has to be done anyway somewhere, and even if it’s our own custom decoder and encoder, that data should live together, otherwise if you’re writing to disk separately you’ll run into issues. So i guess we need to do our own custom encoder/decoder bc it’s not in the LDK objects.
    • Matt: yes, that should be provided for you, there should be a vss client that does it for you. Not built yet.
  • LDK Node
    • There’s been an 0.1 release since the last dev sync. The first non-experimental release
    • It’s all out except python, got kotlin/jvm out today.
    • If someone’s interested in python bindings sooner, ping Elias. It’s a bit of a mess according to the bdk folks, building python packages so it builds on all platforms
    • Slowly starting to look into the next release, prob will happen soon after ldk 116 to incorporate ldk bugfixes and other ldk node fixes
  • Dual funding channels
  • Splicing
    • Holding off on these topics for the meeting after this meeting

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Ken: there’s been a 0.9.1 release with fixes for stakwork. Current release focuses on std and no-std embedded devices, paying attention to heap/stack.
    • A problem is we can sometimes get messages that are larger than ram, so can’t buffer in memory in any one place
  • Synonym (https://github.com/synonymdev/ldk-node-js)
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe
  • Mutiny
    • Tony: Working on VSS and new ldk 116, really appreciate the fixes there, esp around manager/monitor time syncing stuff. Hoping to do an open beta release this week. So far working well.
      • May end up doing something with a prober similar to RGS, think there’s an SoB project for that as well. #1 problem we’re seeing is client side routing, esp w no view of the network.
      • We don’t ship a scorer, let clients make their own scorer
      • Trying to probe with ethics in mind is something to consider
      • Matt: i wouldn’t stress too much about that. One other thing, should talk about whether we probe on our end and ship that on the RGS server and make it a formal part of the RGS pipeline too, so we don’t have every LDK client doing more probing. But also good for probing to happen from the perspective of the LSP being used, so might not provide the same level of quality data
      • Tony: right, we’d be probing from the main voltage LSP.
      • Ben: sth that would be nice in RGS is configurable snapshot interval
      • Arik: there’s a PR for that.
    • Tony: last thing on RGS, last week i raised a missing channels bug. I will open an issue
      • Matt: still investigating that
  • c=
  • Lightspark
    • Tadge: we’re not in production mode yet, but trying things out

Spec

Misc

  • review begs?
Clone this wiki locally