Skip to content

Meeting Notes 2023 10 16

Jump to bottom
Elias Rohrer edited this page Oct 16, 2023 · 1 revision

Releases

Roadmap Progress

  • Developer support
  • Payment protocols
    • Gonna try to get the remaining BOLT 12 MVP PRs (jeff’s) merged for 118, but they may slip
  • Language bindings
    • Swift 117 is out
      • Gonna release 118 shortly after it’s released for rust-lightning
    • 117 for java/typescript is out too
  • Taproot support
    • Arik swamped with RGS debugging. Still trying to repro Tony/Mutiny’s recent issue
  • Anchor outputs (DONE)
    • We had a few feerate fixes on htlc txs that went in
      • There was also a bug where you couldn’t detect your balance if the counterparty force closed a channel. Addressed
    • Will require some manual interaction if you already had a channel force close this way by the counterparty by the time you upgrade to 117, so check out the release notes for what to do there
    • Had qs/concerns raised about enabling anchors in user applications – that's something we need to improve our documentation for.
    • Lots of LSP users that are worried about 0 conf JIT channels w/ anchors – can’t expect users to have an onchain balance, which is a requirement for anchors (since you’re no longer committing fees up-front, need to keep a fee reserve for if/when a channel goes onchain).
      • Our solution: given a trust relationship w LSP, say “hey, if the mobile node FCs, don’t handle anything and let the LSP handle the FC instead” bc they should have that reserve
      • Most LSPs are using LND, so LND will handle the reserve
      • If using LDK for your LSP node, make sure to handle your reserve reqs. Touched on in the anchors blog post. There’s an in-flight PR with expanded docs, but still room to improve here. Probably not in 118, but def 119.
    • John carvalho: in the same user scenario, mobile app w LDK and a trusted LSP - having 0conf chans only works if you do 0conf thru the whole chain. That’s dangerous. Wondering if anyone’s thought about ways to prevent the LDK node from enforcing while the channel is unconfirmed? So “don’t enforce” until the LSP sends a message telling them to do so
      • Matt: so the client paid $ for the LSP to open a chan, LSP opened it, onchain tx never completed but also the channel got FC’d…?
      • JC: want some method to ensure the client can’t claim their channel and double spend
      • Matt: only enforceable way would be to make sure the LSP spends the client’s input in the funding tx
      • TODO: follow up offline
      • Nslaney: “It's pretty smart, make the lsp txn funding dependent on the user's funding txn, so if the user tries to receive a payment, force close, and double spend their funding txn to the lsp, they are just forfeiting their claim to the lightning channel funds, and the channel is null”
  • LSP
    • Nick slaney: no major updates, talking about some stuff with greenlight
  • VSS (Versioned Storage Service)
    • Gursharan out of town but getting close on V1 and jeff to look into V2 after that
  • LDK Node
    • No major updates, mainly 117 upgrade and after 118 lands, we prob finally ship a release w a bunch of accumulated stuff
  • Dual funding channels
    • Jurvis: will start integrating interactive tx stuff, wilmer and i started adding tests within that PR. slowly inching towards being able to put it out for review
      • Dunxen has said he’s pretty happy w it so far. He’s been using our work for V2 channel establishment
  • Splicing
  • RGS
    • Tony: issues are hard to repro and track down. Will keep trying

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)

  • Synonym (https://github.com/synonymdev/ldk-node-js)

    • Have been running into the 117 deadlock issue. Any workaround here?
    • Matt: can check if a channel is funded and present before calling close_channel, should work. Also 118 should be out this week if you wanna wait,
    • Jason: w/r/t RGS, it seems like on android the app can become unresponsive during initial sync. Anyone else noticed that?
      • Tony: yes. A lot of data for low powered phones, it seems. We sync in the background. It’s usually fine though.
      • Arik: 8 seconds is the worst i’ve seen. Usually 2
      • TODO follow up offline

  • Mutiny (https://github.com/MutinyWallet)

    • Tony: not a ton, deployed 117 and started using async storage. We have some bugs on retries we’re figuring out, but otherwise good.
    • Ben: main cause of FCs is the fees stuff, which matt and I have been working on More flexible fee rate estimates to address that

  • c=

    • dom/nick: not much here. Skipping 117 and will wait for 118, looking forward to it
    • Willem: had a couple discussions around anchors, and the # of utxos to keep in reserve separate from the total amount in reserve. Also discussed whether to handle htlc claims waiting for utxos, which sounded a bit more complicated. Long term, looking to more aggressive claim aggregation.
    • Wilmer: we might want to cfg-gate it bc we’d be doing weird spending patterns on the user’s wallet and they should prob be aware that it’s happening. Aside from that, need to come up with the magic #/formula which depends on the # of htlcs in flight and amt of blocks it would take to confirm a single htlc claim tx, so we can determine the appropriate # of utxos to split things up into. Affected by cltv expiry delta.
    • Willem: reccs for mutiny for anchor output chans in general? Does it require trust in the LSP?
    • Wilmer: a mobile node is not gonna be able to really be up to the task of bumping txs continuously, even if they do have a reserve. Even if the app sends notifs to say “open the app to bump tx,” the notification may not be delivered, so it’s not reliable. Atm, we can defer to the LSP to close on behalf of the user. There’s an edge case with LND, they don’t FC on error, so we have a PR up for 118 that will force LND to FC (we mimic their SCB restoration mechanism).

  • Lightspark

    • Oleg: working on recovering funds from FC’d channel. w/r/t SpendableOutputs events, we’ll be able to catch it and form a sort of PSBT signed w NodeSigner and broadcasted when a customer wants it, bc funds also have a timelock. Trying to design sth for the customer so they can FC.
    • Wilmer: use get_claimable_balance
    • Oleg: working on async-ifying some methods and making them fallible.
    • Wilmer: i assume waterson has been busy, but he owes us a PR update (we left some review). The PR is high priority for us.

Spec

Misc

  • review begs?
Clone this wiki locally