Skip to content

Meeting Notes 2022 01 10

Jump to bottom
Elias Rohrer edited this page Aug 11, 2022 · 1 revision

2022 Roadmap

  • https://docs.google.com/document/d/1W-zbVmKLaZUhz0EcI_rYRPWchVusblBdmAeung2aBQI/edit

  • 0-conf

    • Overtorment from BW is waiting on this
    • Remaining todos: Finalizing of the spec, impl in LDK, impl in other impls

  • Jkczyz lots of scoring improvements

    • Probabilistic scoring

  • Arik mobile graph sync

  • Phantom nodes

    • Relevant to enterprise lightning usage
    • Unique feature to ldk

  • typescript/JS support

    • Progressed faster than expected

  • Scaling developer support/resources

    • Youtube, twitch

  • Summer of bitcoin project ideas

  • Payment protocols

  • Language bindings

  • Taproot

  • Anchor

  • LSPs

    • Kinda in steve’s court. Is this a viable project/could there be a shared library here?
    • Popular lightning wallets ~all have an LSP model rn (phoenix, muun)
    • Prospective lightning wallet devs are prevented by the fact that they’ll have to build an lsp along with it

  • PTLCs are on the list but may slip

  • Matt: one potential big change is if fees increase a ton, anchor gets much more important and we’ll have to drop things and work on it. At that point there’s a lot more potential for issues with force closes, things not confirming on time on-chain, etc

  • We’re seeking feedback on this roadmap

Releases

  • 0.0.104
  • 0.1 will mean “we’re happy w the reliability and robustness” not necessarily “we’re up-to-date 100% with the spec” so warnings/payment metadata spec catchup is not necessarily 0.1 criteria

Bindings

  • Typescript
    • Matt: Further along than i thought
    • arik/matt spent time in 2020 but hadn’t touched it since
    • Moving along at a clip. Getting to the point where we could open it up for early alpha testing if someone had a TS/JS project they want asap
    • No doubt there’s some bugs, but full api is exposed
    • It compiles it no-std to wasm then builds the bindings against that
    • Garbage collected bindings building thing was more language-agnostic than expected

Lightning-signer

  • Devrandom: just submitted no-std support for invoice crate. Signer needs it to decode invoices and tie htlcs to payee pubkeys.
  • Mostly will be focusing on productionizing this and getting adoption this year. Rn it seems like c-lightning and greenlight are the most likely cuz they’re accepting our PRs to better integrate CL w lightning-signer and also it makes sense for greenlight to have secure support of customer signing things, seems like a good fit
  • Ken: since the last meeting, we were catching up on tech debt in our unit tests and found that htlc sigs with anchors enabled weren’t matching. Submitted PR for this. We integrated the appendix F of bolt 3 into the test. commitment framework, so we were able to do all of that stuff correctly now in RL
    • Devrand: lends more confidence for anchors

Spec - payment metadata

  • If you have more stuff that doesn’t fit in to the payment secret, this would allow ppl to do the same thing as we’re doing with inbound payments now
  • May be useful for our users
  • Treated like the payment secret – basically a variable length payment secret

Review begs

  • https://github.com/lightningdevkit/rust-lightning/pull/1231 john cantrell: approach acks/feedback on the overall direction plz
    • Want to expose a couple more pieces of info on the PaymentForwarded event
    • Separate issue is the idea of intercepting individual forwarded htlcs (rather than batches of them as we currently do)
Clone this wiki locally