Skip to content

Meeting Notes 2022 10 17

Jump to bottom
Elias Rohrer edited this page Oct 18, 2022 · 1 revision

Releases

Roadmap Progress

  • Developer support

    • Conor: no major updates in terms of dev docs/website. We did just have tabconf, nice to meet people in person
    • Arik did an RGS workshop, not sure how much was recorded yet
      • Have a twitch stream on RGS as well
    • Builders day was good, had one person submitting their first ldk PR
      • Managed to get a few people up and running with the sample
    • Max on call
      • Lexe project is using LDK, working on LSP, then mobile apps
      • Val to fix sample bug that max found
    • Conor: will be sure to share any stuff that was recorded at tabconf in the discord. If there are any things in the sample, will have a focus there since there’s been increased usage as a starter/boilerplate project so if there’s anything we can do to make it easier let us know
    • Ldklite will hopefully be a production ready replacement for the sample node

  • Payment protocols

    • Offers PRs should land soon
      • Not gonna stress too much about the spec changing, can always change it since it won’t be used in prod for a while
    • Then offers messaging
    • The custom onion messages PR will be needed for offers messaging and async payments
    • Viktor’s onion message padding PR in review, wooo

  • Language bindings

    • To-be-updated for 0.0.112
    • New framework should work, plz test
    • Worked in bluewallet project
      • Need to have marcos come in here now

  • Taproot support

    • Not much in terms of code, but had a lot of discussions w laolu/wlmer/matt at tabconf.
    • Also addressed in spec meeting last week – there was a q about storage of musig2 nonces or their deterministic derivation, and have agreed on the latter.
    • Arik to double check the spec thoroughly, may be slight delay in progress there
    • VLS starting to think about multisig/taproot. So if anything comes up in dev, please inform them
    • Arik: the nonces need to be verifiably only used once, so they’ll need to be saved, all will need to live in the keysinterface. wilmer/i thinking about splitting the signer into an ecdsa signer/legacy, and a taproot signer, so you can have old/new versions of VLS
      • → major refactor in channel stuff, channel will have an enum w/ the channel type which will expose the signer based on the type of the channel being worked with
      • Progress on this over the last week, likely moving forward w this
      • Matt: What if we add channel upgrades? Like anchors or ptlcs after the channel is open
      • Obv we can’t convert to a taproot funding output, but might have some stuff that uses a similar interface
      • Arik: either the chan type would change.. For now the enum variants would either be legacy or taproot signer. Signing aspect doesn’t really change, ptlc is somewhat unrelated property. Have one signer that can handle a bunch of diff channel versions, can have 2 types of chans that retain compat
    • Devrandom: let’s sync about these api changes

  • Anchor outputs

  • LSP

    • Jay: call delayed this week, will have an update next time

  • WSP (Wallet Storage Provider)

    • Gursharan: created a PR for the basic get/put interface from last week. After that is review
    • Devrandom reviewed the PR, minor comments

  • LDK Lite

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Working on production readiness
    • Ken: working on STM demo so that persistence works
  • Sensei (https://github.com/L2-Technology/sensei)
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Including route hints for offline channels for mobile nodes is important for us to get in (#1769)
  • Lexe
    • Shared feedback on ldklite, shared feedback/papercuts on ldk-sample and making it prod ready
    • Update on project: currently working on integration test that opens a channel and makes a payment and mines blocks
    • Rn trying to make it so all actors respond immediately. Currently the spvclient chain_tip_poll is once/minute. So we’ll mine a block then wait 60s, not ideal for integration tests. Figuring out how to wire up the node and what events need to notify which actors to process events

Spec

Misc

  • review begs?
Clone this wiki locally