Skip to content

Meeting Notes 2023 04 17

Jump to bottom
Elias Rohrer edited this page Apr 17, 2023 · 2 revisions

Releases

Roadmap Progress

  • Developer support
    • SoB proposal submissions were due last Friday. Evaluating this week.
  • Payment protocols
    • Stateless offers has gone through a lot of iterations, but should be close. Jeff to ping when it’s ready for review
    • Blinded pathfinding groundwork also going through some changes.
    • Next up would be offers messaging flow with ChannelManager, blinded pathfinding itself, and paying/receiving to blinded payment paths
  • Language bindings
    • Tnull: some work on the swift side of things. We made a pet release for 114 since there was a bug, so if you upgraded to the latest version, please pull again from SPM, since swift doesn’t allow point releases due to our version # being too long, so it’s an in-place update. Please make sure to get the latest version from spm. Quite a bit of movement on the swift side of things
  • Taproot support
  • Anchor outputs
    • Current PR has had more progress. At the final step of adding docs + tests, but it’s mostly ready. Now that we’ve decided we’re doing 115, we were hoping to have that in for that, but it definitely won’t make it if we plan to release this week.
    • Matt: we can still do it early in 116 and flip the flag in 116, as long as it’s early
  • LSP
    • Nick slaney: No huge update from c=. About settled with transport layer spec. Thanks to ben and tony for comments on that. Hopefully the JIT channel spec should be finished soon too.
    • w/r/t ldk side, jcantrell is working on the LSP transport layer implementation in the LSP client repo of ldk. Not sure if he needs more review, but just a heads up that he’ll be doing the JIT channel spec as well
    • Tnull: will review that
  • VSS (Versioned Storage Service)
    • G: progress on the client. Looking to add better error handling and a few more test cases. After that, i can start working on integrating it with LDK Node.
    • Elias and Jeff to review
  • LDK Node
    • Tnull: not too much to report since last time, biggest progress is that payment store and kv store should be ready, after a final ack after this meeting i’ll merge that. Then there are a lot of small follow-ups that will land shortly.
    • Close to an alpha release, 0.0.1 and get the docs out so people can play with it
    • Then, on the way to 0.1
  • Dual funding channels and splicing
    • Jurvis will have a PoC PR up in the middle of this week. Good handle on that.
    • For DF, there were some spec updates and chatter in spec meeting this last week. Dunxen will be updating his PR for fuzzing and some other changes soon
    • We want to land 2111 and 2138 before dunxen’s Channel refactor

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Ken: in the past few weeks, been integrating with bolt12, connecting the cln integration tests with the ldk parsing. Almost there.
    • Devrandom has worked on some DoS attacks, so we’ve enforced policy limits now for the number of channels/invoices, so an evil node cannot just connect a whole bunch and overflow memory
    • Implemented a fee velocity limit, eg “i’m willing to spend X amount on fees per day”
    • Some work done improving unit test coverage
    • Coming up, making sure any channel funding tx is not malleable (ie segwit only)
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Jay: thanks for bindings fixes. Been running 114 in bitkit and it’s been smooth, very reliable payments and no crashes.
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe
  • Mutiny
    • Ben and tony are full-time on this now. Nothing to share currently, but interested in the whole VSS and LSP spec projects. May spend time on it in the near future.

Spec

Misc

  • review begs?

  • Ariard topic: rust-lightning permissions, transparency, keeping it decentralized

    • Project has more and more users and contributors. Q is about merge rights and permissions. It might be good for transparency to document clearly the merge rights, just like bitcoin core.
    • Matt: a few things.. We should document it, you’re right. The project is still fairly small in terms of contributor base of people who are doing regular review, which is the threshold for any permissions granted. We have a lot of drive-by contributors, SoB folks who may or may not stick around, but the set of people who do regular review is fairly small. Not sure how much process we need to do. You also highlighted that we should move to merging being the bitcoin core maintainer script, which does pgp signing, etc, and we should. So far, i’ve still personally reviewed everything locally w/o trusting github. But we should move to a more formal process. Been hesitant to suggest it since we’re a small group of regular reviewers. Up to everyone else if we should do this now or wait more.
    • Val: workload overwhelming, i vote dealing with this in 2024
    • Zak: note that we could use something other than pgp
    • Matt: extolls pgp virtues
    • Jeff: we could make this an 0.1 thing (matt: +1)
    • Matt: this wouldn’t require pgp signatures of the ACKs, a little extra for reviewers. Voluntary for bitcoin core to sign signed-off commits
Clone this wiki locally