Skip to content

Meeting Notes 2023 05 15

Jump to bottom
Elias Rohrer edited this page May 15, 2023 · 1 revision

Releases

Roadmap Progress

  • Developer support
    • Conor: disabled help forum on discord in favor of GH Discussions and Stackexchange as our main Q&A platforms. A lot of people on this call prefer discord, but want to highlight there are more static/searchable/web based forums we support. So if you want to ask qs and refer back to them, those platforms may be preferable.
    • Devs have been creating tracking issues for their larger roadmap items w/ checklists: https://github.com/orgs/lightningdevkit/projects/3/views/1 easy reference for the status of big projects.
      • Still need anchors, async payments, and trampoline as of this meeting
    • Summer of Bitcoin projects are kicking off this week
      • Over 10k apps, 45 projects taken in total. 4-5 LDK based projects
      • See #summer-of-bitcoin on discord (may be broken up into multiple channels if it gets too noisy)
    • There’s also the bitdevs meetup in Miami that folks should attend
  • Payment protocols
    • Jeff opened two offers messaging flow PRs, one ready for review
    • Val working on blinded pathfinding, should have an update today
    • Hopefully this week/next week will have route blinding sending/forwarding/receiving PRs open
  • Language bindings
    • Android builds for 115 were messed up bc android’s JNI is different from java’s JNI, and there was an issue with thinking it followed the java spec, but android doesn’t. Should be a fix soon.
  • Taproot support
  • Anchor outputs
    • Updated BumpEventHandler PR, waiting on review now
    • Some parts still need rework
    • Aim is 116 for anchors support
    • This is important for ensuring force closes are claimable.
  • LSP
    • Nick slaney: waiting on feedback for JIT channel spec LSPS 2. Hopefully merging that soon.
    • Zman posted on the ML
    • Jcantrell will keep going on the LSP client, working with Elias on that
  • VSS (Versioned Storage Service)
    • Gursharan: focusing on my existing PRs on client and server side. Apart from that, working on integration w LDK Node.
  • LDK Node
    • Good progress
    • Uniffi bindings landed
    • Followup also landed, quite a few PRs up, namely for RGS integration and 0conf support, and a bunch of refactors and API changes that lead us to upcoming 0.1 release
    • Only piece missing atm is SQLite backend support, which i hope to PR by tmrw (tnull)
    • After all this, good for 0.1
  • Dual funding channels
  • Splicing (new)
  • issues with lnd
    • Wilmer has a PR open to disconnect peers if they’re not responding for too long, which should be the fix. Eclair has had this for a while.

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Ken: finishing up LDK upgrade to 0.0.115.
    • Just finished updating CLN
    • Working on adding HTTP client support, which allows fetching proofs to signer via http
      • Using Hyper
    • Added two SoB mentees, who are gonna work on tuning, one for latency and one for RAM size
      • The amount of RAM limits how many channels we can process concurrently
      • At times, the frontend is feeding us proofs. While processing them, we put them in memory atm, but that takes too much memory. So we need to change those algos to process sequentially as we consume the message
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Jay: not too much. I tried to implement 0conf channels last week, our LSP is only using lnd, which requires anchors. So will wait for 116
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe
  • Mutiny
    • Ben: not much. We put a real mainnet funds on it and made some successful payments!
    • Tony: on the websockets side, websocket tcp from browser is very involved. Luckily all the ldk apis allow us to work around it, but i can see it being difficult for other browser based ldk nodes in the future. Idk the best way to open source some of that, but it is complex to deal with, merging two sockets tgthr
    • Matt: is this on the JS side? Which is complicated? And would it be helpful if we had native websocket support on the receiving node end?
    • Tony: that would be huge. WS spec in ln spec is that it doesn’t do WSS, so that wouldn’t work in the browser context. Lots of edge cases, you don’t always know if the client is connected, and diff browsers handle it in diff ways. I opened an issue recently where we don’t always know if the ldk node is connected to another node, we just know that we’re trying to initiate a new connection, bc some of the apis don’t return whether or not a connection is in progress
    • We do all WS stuff in rust
    • Matt: we should get WS in LDK so more nodes by default are listening on WSs, and then LSP folks can slap nginx in front of lsp node and have WSS, so we don’t have to worry as much about the proxy
    • Tony: that would be huge, i could delete so much code
    • Matt: patches welcome. I’ll check for an issue. Rusty indicated that WS stuff is trivial to write
    • https://github.com/lightningdevkit/rust-lightning/issues/2296
  • c=
    • NS: doing a speed run of every lnd interop bug rn. Thanks for the help!
  • Lightspark
    • Chris waterson: we’re trying to do an enterprise grade LN-as-a-service provider. Most of our stack is on lnd atm, and some issues around scaling.
    • Last couple weeks, looking at reimplementing what we’ve done there in LDK. been fantastic! Thanks for discord debugging help
    • Rn, have a PoC that’s mostly running and doing what we want
    • I started with ldk-sample, pretty straightforward, just copied and pasted code as i needed it
    • A couple areas that would be great – async persistence!
    • A few other interfaces that we make use of and we would probably ultimately like to see be async. One is the router, we do an rpc off of the actual node to get routing info. I finessed that right now with block_in_place
    • Also want to move channel signing out of the node, so it doesn’t have to maintain a secret
    • Just started looking into that, not sure how hard it would be to make async, but ultimately would be helpful for us
    • Other than that, everything has worked as advertised
    • Matt: so router being async… it’s something we could look into. I don’t think it’s a short term thing, but doable.
    • M: On remote signing, yes. A lot of stuff landed a few releases ago to make it easier. There’s an issue for it somewhere, primarily about making those calls more failable, but they could be more async as well. No one working on it atm.
    • M: for async persistence – it’s not gonna be immediate, we want to get most of the stuff in place for 116, then actually use it/enable it in 117. But we’ll see, there’s a lot of things to improve across the stack for that

Spec

Misc

  • review begs?
Clone this wiki locally