Skip to content

Meeting Notes 2023 02 06

Jump to bottom
Elias Rohrer edited this page Feb 6, 2023 · 1 revision

Releases

Roadmap Progress

  • Developer support
    • Spiral folks will be talking to BDK folks this week, end goal is a more integrated experience across those two platforms
  • Payment protocols
    • Async payments:
      • Pushing on moving payment retries into channelmanager right now.
      • 3 PRs open for review on this, at least 1 more upcoming
      • AJ Towns posted a scheme for getting proof of payment with async payments on top of PTLCs.
    • Bolt 12:
      • Fuzzing serialization PR is in review
      • Stateless bolt12 offers is almost ready for review
      • Offers messaging should be quick after that
  • Language bindings
    • Not much here
  • Taproot support
    • Arik: have some PR up that is adding message types. Next gonna add features and a separate taproot channel signer that'll allow for separation of concerns. All these PRs are blocked for merge on some spec decisions and also that they rely on types that are in our own musig2 repo, and we don't want to use that. Also waiting on some upstream changes. But in the meantime, we can do interop testing in the next 2 weeks.
  • Anchor outputs
    • Wilmer: Hadn't worked on it for a bit due to catching up with review, but picked it up last week again. We had an internal discussion about how to handle coin selection for anchors. Decided that you have to consume these anchor events + attach add'l inputs, so the plan is to support two different ways: you can either provide a coin selection and we'll take care of it, or you can give us utxos. If that doesn't work for anyone, let us know. Should have an update in the next meeting.
      • It will not be in 114, likely 115. But this is just handling the events.
      • You could run anchors right now but would need a config flag and the implementation still needs more tests atm
  • LSP
    • John carvalho: generally we got some feedback from the LDK team, channel request spec needs some love. With reputation stuff, we decided to do a generalized project for basically a web of trust, seeing what would be a simple thing we could build there
    • Sev: trying to make the whole spec more modular. So you can choose what you want to implement. And adding details about the flows. Goal is to have a PR open for review end of this week, then everyone can comment on it.
    • Nick slaney: fyi Sev, Z-man is going to look at the spec too. Going to write a draft as well, so we can compare them
    • Matt: how are you thinking about scope creep here? Seems like a lot here
    • JC: scope of the group != scope of the channel spec. I think this confusion comes from (1) not explaining the api calls and (2) the inclusion of lnurl channel as a format of delivery. Beyond that, we considered the spec as far as features done, so we don't plan on adding more to that spec
    • Matt: was referring to marketplace stuff, is that moving out of the spec?
    • JC: unknown. My views on the marketplace may differ from the group's. Not of interest to me personally, i think interop of an LSP itself is good enough.
  • VSS (Versioned Storage Service)
  • LDK Node
    • Elias: Good progress. Thanks jeff for recent review on main PR, which is the initial implementation. Apart from that, tx sync crate PR upstream is getting close. Also made progress on language bindings side of things - kotlin/JVM working well, now looking into porting that jvm version onto android so it runs in a simulator (getting close).
    • Bitcoinzavior: flutter updates: we have the flutter package ready. It's not a language binding bc flutter is a framework so it's an overall flutter package. Lately been testing it a lot from within a different flutter app, which surfaced some issues. Some were misunderstanding how ldk node works, and some were related to txs. As LDK Node progresses, i'll be making updates to the flutter package in parallel. Long term goal is to get the flutter package ready first and when that is done, initiate the react native module.
    • If you want to try it out, just clone and run the example app, no need to install anything. Example app exposes all methods of LDK Node from the app side.
  • Dual funding channels
    • Dunxen from discord: "Won't be able to make the Monday meets for a while as there's a clash with an evening class of mine. I've rebased and responded to feedback on dual-funding messages for #1794. That's resulted in some changes on the interactive constructor which is still WIP. I'll probably push as draft anyway for early feedback."
  • Splicing (new)

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Devrandom: we're done with our mvp 1 milestone, which means we think everything should work, but not all the security features are in. finishing the security features will be mvp 2, which hopefully will be ready in 2 months or so.
    • We had the security audit by antoine published and are mitigating some of the issues that were found
    • Making progress on UTXO oracle
    • Also thinking about multisigner and noticing that revocation in this environment is unsolved problem
      • Problem: if you're in a multisigner environment, the question is how do you construct a secret that can only be disclosed by a threshold of signers. Seems hard bc there's hashing involved. So then you can do maybe multiple secrets for every tx, but then that's more complexity - so basically the problem is secret disclosure with a threshold of signers, don't want a single signer to be able to revoke a tx
    • Devrandom: is there some estimated date for the release?
    • Jeff: two weeks ago. We're reviewing a bunch right now, getting close. Hopefully a week or two.
    • Ken sedgwick: on CLN side, we're working with dusty on splicing. So i think we should get together with dunxen and make sure it all fits together. Specifically thinking about what the signer needs to know and do for a splicing tx.
  • Sensei (https://github.com/L2-Technology/sensei)
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • JC: pretty much done upgrading to 0.0.113. A bit of a headache and he's currently having headaches with M1 vs different macbook chipsets. Still having issues getting payments through as far as testing. Trying to make progress there but Jay would be the one to speak on that. Also having weird bugs maybe related to millisats, seems like not able to do payments under 1000 sats
    • Matt: i know we resolved the problem around routefinding because there were two netgraphs in memory, was there another one?
    • JC: not sure. I would get an invoice in text and would see it as 0 amount, then see an invoice in QR and get a normal amount. Paying both would fail due to no route found/no hints given. I asked Jay about it.. You'll need to talk to him about that.
    • Corey: we were looking into the feerates when setting up the channel. Could be an issue with our RN implementation. For example, min htlc/max htlc when setting up with ldk seems to be off. E.g. max htlc set is ~10% of the max capacity of the channel. And the min htlc is also really high, so anything less than 2000 sats will fail. So there's this weird feerate issue that could be causing the no-path-found error
    • JC: IIRC some of the errors might be from the lnd side
    • Matt: please talk to us about issues
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
    • Shamardy: i updated to the latest version, 0.0.113. I left an ldk-help chat message, related to claiming part of a payment on chain. Matt mentioned that this right now is failed by ldk, but for swaps purpose i need to claim this payment on chain using the preimage. But in ldk, the channel is already closed at this point. So, should this claiming be done outside of ldk or will it be supported by ldk in the future?
    • Matt: let me get back to you. We might've already changed that, but we can make it more formal. I'll open an issue and ping it on discord
  • Lexe

Spec

Misc

  • review begs?
Clone this wiki locally