Skip to content

Meeting Notes 2022 06 27

Jump to bottom
Elias Rohrer edited this page Aug 9, 2022 · 2 revisions

Discord vs Slack

  • Ariard: some people are on discord, some on slack, etc.
  • Steve: discussing exclusively posting new stuff on discord, but we’ll keep slack around til it dies off? Is that the proposal? I’m on board w/ that
  • Can’t keep slack msg history due to per-user cost, doesn’t work for public slack, like 100k/year+
  • Steve: we may see a natural migration to discord if we mostly post there
  • Jeff: could encourage active people like overtorment to move over there
  • Would be nice to get commit-stream over to discord, etc

Releases

Roadmap Progress

  • Developer support
    • LDK Btc++ talk w/ jeff/arik, check it out!
  • Payment protocols
    • Jeff working on offers invoice format, should get draft PR out soon
    • OMs v1 ready for review, may move some code around
  • Language bindings
    • Someone requested elixir support?
    • Matt: GLHF with that
  • Taproot support
    • Arik: not working on this quite yet cuz the bindings and server side need to come first, however was just talking about taproot things in LA for plebfi, very helpful for using TR with rust-bitcoin. IIUC the plan is for wilmer and i to collab on taproot. Discussed approaches of step by step guide w channel support flags and commitment tx support, so at this point the path is relatively clear. Hope to get progress landed in Q3
    • Wilmer: in reference to roasbeef’s “simple taproot” proposal, which hasn’t gotten much review, as a prereq we need anchors so i’m currently working on that
  • Anchor outputs
    • Wilmer: been chatting w matt and ariard over the past week. We’ve identified two paths of exposing anchors: (1) we require users to impl some interface, which would be the missing bits that happen externally to ldk, then we handle the fee bumping ourselves, request utxo from user’s onchain wallet, manage it ourselves, or (2) event path, similar to how funding channels works w/r/t FundingGenerationReady events etc. when it comes to mempool edge cases, wanna make sure users are crafting a tx that’s valid and would actually propagate
    • Event path: lil more tedious for the user in the sense that they have to worry about these additional things, but also it is a good step forward as an initial step
    • John cantrell: i always prefer bubbling events up to the user so we can handle it. Prefer more control than less as a user
    • Matt: even if we do something other than events, we can’t enforce users to have enough btc. On package stuff, one req is that “you must not fund this tx with inputs that are unconfirmed”, if you do that we’re screwed. But not clear what we can do better or worse there
    • ariard/wilmer: we should check those things, like lnd does
    • Matt: but then we’re building an onchain wallet
    • Matt: v1 we have the events interface, v2 we add safety logic into ldk via a wrapper that consumes those events, deals w utxo spending, and does checking of total balance. Obv would have some kind of method to communicate to the user how much balance they’re expected to maintain
  • Lightning Service Provider (LSP)
    • John carvalho: got a core group of lsp builders together talking to each other, plus zero-fee-routing node, others

Dependent Projects

Spec (https://github.com/lightning/bolts/issues/1002)

  • Zero conf nits #998
  • Channel update flags #996 or #999
  • Grace period for older channel updates #1001
  • Hold htlcs before forwarding #989
  • Add dust exposure threshold #919

Misc

  • review begs?
  • Review Club
    • It was requested to switch to audio, prob will try that this week
    • Jeff: my suggestion is a mixed variation, has audio and text
    • Suggestion: review club on discord call
Clone this wiki locally