Skip to content

Meeting Notes 2023 06 12

Jump to bottom
Elias Rohrer edited this page Jun 12, 2023 · 1 revision

Releases

  • 0.0.116 (https://github.com/lightningdevkit/rust-lightning/milestone/33)
    • Looking good, will prob be the first or second week of July
    • Packed release
    • Still hoping to get anchors in there
    • Will get some bolt12 stuff, not everything but close
    • Should get LSP support
    • There’s a lot of issues left that don’t have PRs, mostly feerate handling improvements/dust handling. If anyone has time, would appreciate a hand. One is just changing a default
    • This week by the end we’ll know better where we are, hoping to get a lot of stuff merged and have more confidence about the timeline
    • Focused review would be good
  • 0.1 (https://github.com/lightningdevkit/rust-lightning/milestone/1)

Roadmap Progress

  • Developer support
    • Conor: Spent the last 4-5 days at the BTC Prague conference. Wed was the dev hack day, did an LDK Node workshop similar to what was done at advancing bitcoin/btc++. This time was a bit more of just watching elias go through an hour tutorial, bit less of people doing it hands on themselves since it was short. Went well, positive feedback.
    • Elias: 40 or so people attending
    • Conor: i prefer the advancing bitcoin model with 2-2.5 hours, and tables in the room and light touch info about how to use LDK Node with people figuring it out themselves. (elias: +1)
    • Will aim to make an online stream of this as well
  • Payment protocols
    • Bolt 12 message handling is under review, should merged in the next day or so
    • Blinded pathfinding needs review, should be close
    • Hoping to get further route blinding PRs open in the next week
  • Language bindings
  • Taproot support
    • Arik has put up a few PRs that are integrating things, but we’ve hit a roadblock in how we should go about integrating this stuff. Matt wanted to see how some of the follow up work would look before moving forward, but things are still early
    • We were trying to aim for interop in the LN summit, but not sure that will happen. We’ll see how much progress we make in the next two weeks, but that will mostly fall on arik since wilmer will be finishing anchors
    • Spec-wise, we still have a disagreement but it’s minor and we can hash it out in person in <5min. Taproot gossip – people have decided we’re going to discuss that in person as well. Other than that, everything’s looking good.
    • Still some things to figure out with coop closing, it needs to be turn based so the nonces need to be in a certain order. Also sth to discuss in person in NYC.
    • TR right now only exists for the existing single sided channels, so it needs to be adapted to dual funding. When splicing gets deployed, will need to be adapted to that as well.
  • Anchor outputs
  • LSP
    • Jcantrell: transport layer is pretty much finalized, hopefully merged this week. I went on to work in JIT channels, bc that’s what we’re interested in first with c=. Got that working e2e on ldk-sample on friday, minus a few things. There’s one PR that we need, allow forwarding less than the onion (https://github.com/lightningdevkit/rust-lightning/pull/2319), so the LSP can take an extra fee. And i still need to get it to work with 0conf channels, but should be a minor config change
    • Quite a lot to fix in the actual client for LSPS2, i tried to go deep to get it working and go back once i understood what the interface could look like. Code itself in ldk-sample is pretty minimal, so any wallet built off of that should be able to integrate in a dozen LoC or so. Hoping to get a wallet testing in the next few weeks
    • Benthecarman: test in mutiny
  • VSS (Versioned Storage Service)
    • Gursharan: since we last talked, was able to run VSS integrated with LDK Node. not merged yet. Currently working on the delete API and its implementation, which is a new api that is required for the LDK Node integration. Once the delete api is merged, we can go ahead with the LDK Node PR.
  • LDK Node
    • Elias: i put an alpha 0.1 release before prague, which included at least since the last alpha pretty major things. Not new but finally merged, such as language bindings support and KV store and sqlite backend, etc.
    • Ironing out some things in the api, getting close to release. Going into the struggle with swift and java publishing things, then 0.1.
  • Dual funding channels
    • Jeff: Splicing meeting last week, and jurvis now back at work, have one of the refactor PRs close to merge. I’ve been reviewing that and wilmer/matt as well
    • Matt: channel split refactor is blocking several things in 116, so would be great to get it merged today/tmrw
    • Dunxen to fix CI
  • Splicing (new)

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Released a version 0.9.0, calling it beta-1
      • Has a lot of stuff that enforces policy and makes it safer to run
    • Next release will focus on low resource signers, squeezing mem usage so we can operate on embedded controllers etc
    • Currently working on state recovery with stackworks and sphinx, so they’re working on making backup states and recovering from those
    • Large effort in payment tracking, making sure we’re tracking htlcs correctly so we can garbage collect them
    • Not blocked on anything from ldk, but looking forward to anchors
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Corey: not too many updates, but we just merged the upgrade to 115 which is working well. I’m wrapping up handling reorgs in LDK, going well.
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe
  • Mutiny
    • tony: things working well, working on some storage improvements on our end. Opened an issue about panicking when a state has fallen behind, panics are hard to work around when that happens even though there’s a suggestion on what to do, we can’t do anything bc of the panic. That’s a bigger issue we sometimes have
      • Worked around using localstorage browser api, though that’s not the best. Need the async api
      • Matt: would like to better understand storage issues before we jump to not panicking on what is an assumption violation that might lose money
      • Updates on async traits?
      • Matt: made good progress, on track for it to be in 117
      • Tony: cool, i think a lot of issues would be resolved once we have that but we’ll see
    • but other than that, opened up 2345 where we’re too fast and people are creating invoices fast and the expiry will appear expired bc there’s no block that has synced yet when someone has created an invoice. But our workaround is to not allow invoice creation until block sync. Aside from that, started on mainnet and only have occasional force closures
    • Ben: only other thing on our end, trying to ldk version of SCB via storing monitors, and we can’t send the bogus channel reestablish msg with what’s publicly exposed in ldk right now. Tried to look into a PR but seems involved. 1565 issue seems relevant
    • Matt: that won’t happen for 116… you should theoretically be able to do it currently, but not trivial. That is sth we should do eventually and can think about for 117 depending on what else is going on. Can you open another issue for it? 1565 is a bit diff
    • Ben: ok. My concern was if we manually created the message, encrypted and sended it, my understanding was with LN you resync keys all the time…?
    • Matt: should be fine, can do it via custom message handler. But really want to not have a channelmanager and impl the channelmessagehandler trait itself, so have an object that contains the channelmonitors and sends the bogus reestablish message
    • Steve: related, ben and i chatted if they were interested in VSS. they also want VSS phase 2, phase 1 focused on backup/recovery and phase 2 is multi device access. Just wanted to reiterate that there’s interest in collaboration on that, if mutiny wants to prioritize it the spiral team will move it up in priority. So let’s huddle about that
    • Ben: our plan is to do it sometime this year, so yes sg
  • c=
    • Dom: no updates, using LDK just fine. Digging into persistence a bit. May have sth to submit upstream to improve default filesystem persister in the next few weeks
  • Lightspark

Spec

Misc

  • review begs?
Clone this wiki locally