1 Meeting Notes 2023 03 20
Elias Rohrer edited this page 2023-03-20 18:59:44 +01:00
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Releases

Roadmap Progress

  • Developer support
  • Payment protocols
    • Main focus is BOLT12 right now, val to review stateless offers asap
    • Jeff to split up offers message flow PR, or at least add some commits to it
    • Delaying async payments work in favor of supporting paying blinded payment paths
    • Some discussion recently on bolt12 + LSP spec
  • Language bindings
    • Elias: On the swift side, 114 should be pretty close/ready to go
  • Taproot support
    • Arik: Not this week, since thatll be focused on reviewing anchors work, but later in the week will get back to this
    • Wilmer: there was a cool spec update on this last week. Elle from LL posted a draft and we discussed it last week, will be reviewing that and hopefully we can get it through soon
  • Anchor outputs
    • Lots of PRs open right now that need review
    • Want some concept ACKs on the final bump PR
      • Matt: will do this
  • LSP
    • Steve: would hate for 0conf JIT protocol offers to create a spec that isnt compatible with async payments/bolt12 due to lack of knowledge.
    • Sev: so in the meeting last week, we talked about JIT channels, which mostly registers a payment with the api, and invoices are created with a specific route hint. Zman made a new proposal there, review welcome. From channelrequest api, its getting more mature now, we were talking about channel batching+conf speed, and grpc support, and 0 channel reserve. One question came up from breez: how can we do batching with 0conf channels? If anyone has ideas on this, wed be happy to get some input
    • Matt: you just do it? Why are there specific restrictions on it?
  • VSS (Versioned Storage Service)
    • Gursharan: per the LDK roadmap, we decided to split the VSS project into 2 phases. Phase 2 covers multi device, phase 1 is single device backup, and cloud as primary storage for lightning state machine. As for current progress, im focusing on testing the server side PRs, and integrating encryption on the client side, and looking at getting VSS into LDK Node.
  • LDK Node
    • The main PR finally landed, #11. So if you check out the main branch now, you can build/use it. I encourage everyone to give it a try. Now the review has moved to payment storage. I put up a milestone/issue tracking for release 0.1 https://github.com/lightningdevkit/ldk-node/issues/45
  • Dual funding channels
    • PRs in for review
  • Splicing (new)

RGB?

  • Saw a request on discord from zoe for adding support for assets over lightning
  • Zoe: i would like to make a PR, but seems better to add some hooks in LDK
  • Matt: can you explain more the set of changes required in ldk?
  • Zoe: for now, we need to change the commitment tx. So whenever the method that constructs those, we need another method that adds the op_return output, which allows to move the rgb assets across the channel. Same applies to htlc transactions, and for the funding, thats not an issue bc theres already a hook available.
  • Matt: so to be specific, the changes in the commitment tx are adding additional outputs. So if there were hooks to add addl outputs that dont touch the rest of the commitment structure, that would suffice?
  • Zoe: yup. And for TLV, if its possible to add fields that other nodes can ignore. Not sure about this part, i havent seen custom fields that can be added to existing TLVs.
  • Matt: 2 ways to go about that. Could add it in a separate message that flies before the commitment_signed msg, so thats possible, though not as clean as adding addl tlvs. As for the commitment tx itself, i know arik/wilmer were taking a look at doing some cleanups to the channel logic to make that easier, to add new outputs on the tx. Def something we want to support.
  • Wilmer: ill open an issue for tracking this. Were working on a path forward for this already

Dependent Projects

  • VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Devrandom: we released the final 0.2.0 last week. Ken has been testing it with clboss on testnet, seems to be working fine.
    • I wonder if it makes sense to integrate VLS with LDK Node? Is that something you think is relevant?
    • Steve: it would make sense to me if vls is running in a phone secure enclave firmware. Otherwise, i dont see the need to have VLS and LDK Node on the phone together. There might be an LDK Node Server, then you could have more of a greenlight architecture (imo thats more complexity than necessary)
    • Devrandom: didnt realize LDKNode was mobile-focused
    • Elias: not much missing thats useful for servers. Likely we have some kind of server compatible version. How that will be delivered, as a daemon or as a library like LDK node mobile, open q
    • Ken: been running VLS in socket mode, and using CLBoss to drive it. So we put our mode in permissive mode, not fully enforcing yet, bc that would require advanced policies. But it allows us to tune things, such as heap storage were using, and making sure we have consistent warnings so whenever we run things that would normally require explicit permission, warn. Also streamlining docs.
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • No updates, but will take some qs offline on discord this week
    • John carvalho: jay will be looking into using the 114 bindings soon.
    • Having an issue with the max htlc config not sticking. We want to be able to send the full channel balance, and ldk defaults to some lower percentage for the max htlc
  • Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
  • Lexe

Spec

Misc

  • review begs?