Skip to content

Meeting Notes 2023 08 21

Jump to bottom
Elias Rohrer edited this page Aug 21, 2023 · 1 revision

Releases

Roadmap Progress

  • Developer support

    • Merged a PR that adds a bit more info on channel closing and when you have some outputs that are onchain and spendable by LDK. tnull wrote some sample code that uses a BDK-based wallet https://lightningdevkit.org/key_management/#spending-on-chain-funds
      • Next iteration will add swift/kotlin example code
    • SoB students are finished. Final reviews this week. If you’re a mentor and have not received a correspondence about that, let Conor know

  • Payment protocols

    • Chugging along, hoping to merge a lot of stuff that’s close this week to get closer to unblocking the major final PRs

  • Language bindings

  • Taproot support

    • Arik to put up follow up PR with new taproot signer up today

  • Anchor outputs (DONE)

    • There’s a PR from ariard adding some docs open, but not a ton of activity otherwise
    • Seeking feedback from downstream users on the API
    • c=: planning to use anchors, but haven’t gotten started yet
      • Once we finish some integration tests, will be moving forward with anchors work
    • Lightspark: using anchors, seems to work fine!
    • VLS: we are using anchors

  • LSP

    • Nslaney: sounds like LDK may not support LSPS4, favoring bolt12 instead. B12 requires everyone to adopt, where as LSPS4 ephemeral scids is only on our side
      • We’re working on LSPS4
    • Matt: we may adopt LSPS4
    • LSPS4 is an upgrade to LSPS2 that allows us to take care of a bunch of edge cases where if a user is trying to open a channel/recv payment, we can tell the user about the payment before opening the channel so they can tell us whether it’s valid. It’s compatible with PTLCs in the future, checking with the user before opening a channel is valuable. We’re debating rn whether LSPS2 is good enough, esp in the case where the user provides the preimage up front. LSPS4 is the future end state.

  • VSS (Versioned Storage Service)

    • Gursharan: we published an initial version of the VSS client. Also created a PR for the LDK Node integration with VSS. currently i’m working on a CI integration test so we can spin up a VSS instance and run some ldk node tests against that in our CI builds
    • Have we finalized an interface in LDK persister storage?
      • For now, the interface is going to be in LDK Node, but we are upstreaming the main interface of KVStore into rust-lightning.
    • Summary of runtime aspect
      • One of the things was VSS KVStore will have its own multithreaded runtime. Earlier we were checking everywhere if we’re currently in runtime or without it, and that was mainly for LDK Node because VSS KVStore could be called with/without the runtime. But now since we also have to upstream this impl, it made sense for VSS to have its own runtime

  • LDK Node

  • Dual funding + splicing

    • Meeting last week
    • Duncan has a PR to refactor the channelmanager to include all channels in one map. That’s a prereq to all the work he’s doing. Wpaulino to review
    • Next PR is actually implementing the DF proposal
    • That’s without the interactive tx constructor being written by wpaulino/jurvis
    • Have a few qs around the new api flow for opening DF channels. Do we want to reuse funding_transaction_generated in any way, since now the funding tx inputs are being collaborated on? Do we have to change the api? Still tbd.
    • Matt: i think that’ll have to be a new event(?)
    • Wilmer: if we want to make it collaborative… means we need to screen each input the remote party adds back to the user thru the api
    • Matt: we’ll wanna simplify the protocol in the api. Is there some way to figure out when our counterparty is done adding inputs?
    • Wilmer: it’s weird, there’s a txcomplete message but it means 2 diff things, if cp sends an update then you can send txcompute to ack it, but you can still send more stuff. So it’s not until both sides send txcomplete successively that you can consider it done
    • Matt: let’s look at how others implement it. Send init_chan, then a few outputs, then send tx_complete. If so, we can recv open_channel_v2, see they wanna open a channel, wait til they send a tx_complete or 30 seconds then hand an event to the user saying “this peer wants to open a channel, plz give us some outputs” then let the user send a few outputs and consider it done. Also need to think about how this works for batch opens. Maybe flag channel opens and say “i want to batch this” and here’s some token to track all the batches. Once we have that, then the user can say “here’s all the inputs i wanna add to this batch and how to break the amounts out to each channel.”

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Devrandom: we released vls 0.10. Focus was on low resource signers. Stable since then.
    • Been participating in bolt 12 PR review to make sure it works with vls
    • Will be watching taproot stuff more closely going forward
    • Ken: found out sled was not persisting data durably. So we replaced our sled use with REDB
    • SoB student will be working on some docker imaging for vls
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Upgraded to 116 and starting to test it in the app
  • Mutiny (https://github.com/MutinyWallet)
  • c=
    • We have a persister PR open in rust-lightning, under review
    • Also have a PR open for batch funding for v1 channels. Looks like the approach seems sound, discussing details around closing channels when the batch fails atm
    • Matt: will take another look today and in the context of the DF api, would be nice if we ended up reusing some of the structures there, so want to think about how we track which channels are part of a batch
  • Lightspark
    • Waterson: i’m figuring out if there’s a way to do the commitment point and secret release so that it doesn’t have to rely on those calls being synchronous
    • Getting into some prototyping now
    • Thinking was if we could restrict it so you only ever needed to know the current commitment point and the previous secret, or if you were willing to say “i’ll keep all secrets from prev states if needed” then only 1 place you need to actually get a new one. Obv when you open a channel, and then when you advance the state. Seeing if i could squeeze stuff into those two places instead of asking for them
    • Matt: i like the current PR, just the one during commitment signed processing where we still don’t allow it to fail, so we need to store it as an option and make the places we try to fetch it fallible, and retry
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe

Spec

Misc

  • review begs?
Clone this wiki locally