Skip to content

Meeting Notes 2024 02 05

Jump to bottom
Elias Rohrer edited this page Feb 5, 2024 · 1 revision

Releases

Roadmap Progress

  • Language bindings
    • 0.0.121 bindings out for java. Swift should be out today
    • Some C# fixes coming soon
  • Developer support
  • Payment protocols
    • Progress on iterating on the async payments protocol and adapting BOLT 12 to support it with other lightning implementation devs
    • Val presenting on async payments at btc++ in a few weeks
    • Progress on an (early) proposal for payment notifications, lightning with a payment terminal
    • Going to wait on using 3-hop blinded paths by default until we see how reliability goes with 2-hop
    • Jeff to work on a smaller blinded path encoding for smaller offer QRs
    • As people can tell, Spiral has been in full swing on various new protocol development, point-of-sale/async payments. Also there’s a proposal from t-bast for DNS-based resolution of payment names, so human readable names using DNS rather than HTTP. matt spent some time working on a standalone dnssec prover, so you can get a compat proof that a DNS record is valid and share that around and verify it without internet connectivity. Anticipate we’ll be able to use that in LDK, so we’ll be able to pay human readable names in LDK with this protocol and without any 3rd party libraries.
      • Tony: would love to see more end to end examples of DNS addresses working because it's a bit abstract and I'm doubtful
    • Other payment protocol work: “mutual message exchange” based on onion messages. If sender/receiver whitelisted each other, they can exchange a message as part of a payment. Intention is for regulatory compliance, though people might not like it. Entities that have an obligation to regulatory compliance can exchange info when exchanging messages w/ other entities with regulatory compliance, e.g. the travel rule. Hoping that the fact that there is a better protocol for it allows people to do it in a sensible way, rather than the current system of “tell coinbase all your addresses and let them tell you whether you have a compliance obligation.”
    • Matt should have a full-featured example in a week or two
  • Trampoline
    • Want to land 2756
    • Even though the TLV ids are provisional
    • Before we add user APIs for trampoline payments, want to finalize the TLVs
  • Taproot support
  • Anchor outputs (DONE)
    • Elias worked on integrating it into LDK Node recently
  • LSP
    • With the lightning liquidity crate, merged a few more
    • Elias: we could do multiple alphas, client side is pretty much done for now.
  • VSS (Versioned Storage Service)
    • Gursharan working on changes to our ability to attach custom headers in the VSS request and figuring out with Elias how to expose that in LDK Node.
    • Also a blog post for VSS launch
  • LDK Node
    • Elias put up a few minor API change PRs
    • Users keep stumbling on this – LDK Node automatically generates a seed and stores it to disk if you don’t configure anything. Mobile users keep being confused by that, where the seed is stored and what’s happening there. While it’s nice for testing, it encourages bad behavior around seed storage. We still allow it with the new API changes, but we mandate everyone configure the seed in the builder and consciously decide how the seed is provided.
  • Dual funding channels
    • Wilmer: we’ve lined up some prerequisite refactors, still one more to go that already got some review. Review needed here. Once those are in, dunxen will continue working on the actual implementation of the DF handshake, using OpenChannelV2.
    • Interactive tx PR still hasn’t had its review addressed, wpaulino likely will pick it up.
  • Splicing
    • Not much
    • Still trying to get quiescence over the line, but blocked by an existing PR which wpaulino will get back to

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • DF/splicing work continues
    • Finishing work adding an explicit revoke holder commitment in order to support the node persisting the new valid holder commitment before revoking the old one
    • Interested in DNS-based human name stuff for protocols – might be displaying some of that on a VLS screen. So would love to understand if there are size limits
      • Matt: one variant – you put a node in the DNS, and request the offer from that node, with the understanding that many services will have millions of users and don’t want to have millions of DNS entries, and in that case, matt wasn’t anticipating it being fully provable, but could rethink it.
  • Synonym (https://github.com/synonymdev/ldk-node-js)
  • Mutiny (https://github.com/MutinyWallet)
    • Ben: working on updating from 118 to 121
  • c=
    • Dom: in general, doing the upgrade to 121 as well, but it’s pretty straightforward
    • Willem: been talking to elias/gursharan about how to support more authentication methods in VSS client. Initially we were thinking of wrapping the VSS client in a trait, but that makes it hard for bindings. Writing up a PR for the solution we landed on.
    • Gursharan: i worked on some sample code but elias is unsure whether it will work in the bindings
  • Lightspark
    • Wilmer: Been working on async signing, which has made some good progress recently
    • For the channel bits, it’s close with some final comments from matt. Onchain bits also have a few outstanding feedback pieces. Both should be in the next release

Spec

Misc

  • review begs?
Clone this wiki locally