Skip to content

Meeting Notes 2023 05 01

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

Releases

Roadmap Progress

  • Developer support
  • Payment protocols
    • Jeff working on wiring up offers to OnionMessenger
    • Val opening blinded pathfinding PR today, and the rest of route blinding hopefully this week/next
  • Language bindings
    • 115 working
    • Some updates on the swift end for 114 and some further bugs fixed in 115
  • Taproot support
    • Spec on track, going to be arik’s focus this week after 115 swift is done
  • Anchor outputs
    • We want this for 116
    • Wilmer pushed an update to the BumpEventHandler, had to do some fee estimation there so figured w the upgrade to rust-bitcoin 0.30 they included some stuff we can use. Not strictly required, but we also need to do the bump anyway so might as well get it
    • Other than that, it’s ready for another look. Wilmer to do another pass and take it out of draft today/tmrw
    • Arik to review this week
    • Ariard rebased his anchor PRs as well, to-be-reviewed this week
  • LSP
    • There’s an LSP crate being worked on now in LDK
    • Jcantrell has been working on this crate with elias. Have a design review planned tmrw, hoping to wrap that up soon
    • On the LDK end, we still need to do the thing where we can accept a lower valued HTLC than specified in the onion
    • Nick slainey: pretty sure that’s correct
    • There’s a PR out there for the feature signaling too (jeff has a custom feature bit PR up that was the focus of the review club last week)
  • VSS (Versioned Storage Service)
    • Gursharan: on the client side, progress on error handling and test cases. Working on integrating with LDK Node, should have an update on that soon
  • LDK Node
    • There was an alpha release!
    • Time to spin up your more formal testing for this
    • Exciting
  • Dual funding channels
    • Jurvis: there are 2 PRs right now that are about to land, from dunxen. First one is message definitions for DF and splicing, and 2nd a refactor of splitting the Channel struct. Once those are done, dunxen and myself have been working on establishment flow and interactive tx construction flow. Have had some good discussions on that, working closely to figure out establishment flow handoff to tx construction flow and vice versa. Hoping to gain momentum over the next few weeks
    • Matt: we should land the messages PR this week, but the channel split PR is a little blocked on some other stuff, so we need to make progress on the channel monitor event blocking stuff first, which needs some review
    • Wilmer: messages PR is also blocked on another pending dunxen PR atm
  • Splicing (new)

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Devrandom: still working on beta release. Hopefully 2-3 weeks. I think we got what we wanted from the bolt12 stuff
    • Ken: bolt12 parsers integration seems to work with cln integration tests. There are a couple features not stand that cln does test, but rusty moved them to a separate test. Seems like the first round of integration is complete there. Also makes sure we have a generic view of bolt11 and bolt12, so we can handle an invoice of either type throughout the code
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Jay: not much to report. Going through the review notes you gave us this week
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
    • Shamardy: been working on other stuff for the past few weeks, but back to working on lightning integration with ldk. Thanks matt for the PR that fixes the claiming on-chain.
  • Lexe
  • Mutiny
    • Ben: things going well. Have a couple PRs open on the channel address stuff. We talked a bit in PR comments, but my main goal is to have two ways to close a channel. One is the default to the bdk wallet, the other is a dynamic for special cases. Matt pushing against it
    • Matt: the goal is important, it’s just not clear to me how best to accomplish it. In current PR, we are up to 3 diff places in the code that controls how/when/why the shutdown script is selected (ie this PR adds a 3rd). Confusing api.
    • The reason it’s in the sign trait is we need sth for inbound channels as well, if we’re doing upfront shutdown scripts, we need to be able to fetch it dynamically at the time they request it.
    • Ben: someone else has a PR with get_shutdown_script taking a channel id, meaning we’d have to have a mapping from channel id to addresses we want, like we’d need to have some ugly storage just for that…
    • Matt: yeah, we should def pass channel_id into that request, but i get that, it’s more complexity on the user end.
    • It’s confusing in the spec too. You can optionally set a script at open time, and if you set it, you have to reuse it at shutdown. If you don’t set it at open time, then you can change what you want to do at close time and can pick any script. Today, it’s in the config object, you set a bool as to whether you want to do upfront shutdown script. Based on that, we call into the keysinterface at different times and request a shutdown script, but we always request via that interface. We always req it, but at diff times based on the config. ..
    • Wilmer to chime on
  • c=
    • Sent force close issue to LDK<>c= chat

Spec

Misc

  • review begs?
Clone this wiki locally