Skip to content

Meeting Notes 2021 07 12

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

0.0.99 report

  • Bunch of review and fixes

0.0.100

  • Mainly update_fee pipeline redo and fixes
    • Rare force closes can occur currently
    • Issues negotiating closing fee causes incompat w/ other nodes
  • No_std
  • Keysend
  • No specific timeline at the moment

0.1.0

  • Not 100% definitive what’s going in yet

No_std

  • Rust-bitcoin #603 is close to mergeable
    • Poelstra promised final review + matt should review
    • Hopefully merged in the next week
  • GeneForneau PR in RL
    • PR is not updated
    • Miron pinged Gene to see whether he’s working on the synchronization primitives for RL no_std, no reply yet, miron will ping again and maybe jump into it if there’s no reply
      • Sync primitives need no_std flags in rust-lightning

Keysend

  • Jeff to give more feedback
  • Ready for more review
  • Val to have sample PR ready shortly after RL PR is finalized
  • bLIP in progress

Concurrent domino fee bumping #989

  • Related to anchor outputs
  • Q about the UX for bootstrap phase if don’t have utxos
  • Antoine: we want to avoid 1utxo/channel, gets expensive
  • Qs about aggregating cpfp outputs to cover channel reserve(?)
  • Part 1: antoine to implement domino fee bumping to go before his other anchor PRs.
  • Lots of small adjustments to do for anchor
  • Dependent on package relay and other mempool changes
  • Matt explanation of domino fee bumping: don’t think the current design is more dependent on mempool changes than anchor outputs is, period. Still requires some feerate prediction, needs enough to get into the mempool even if not confirmed, and we’re not changing that assumption. If counterparty pins their commitment tx, (pinning = they broadcast commit tx then broadcast tx-chain underneath on anchor output, that’s a large absolute fee and maybe less large feerate so it won’t get confirmed and you have to pay for that relay to replace that tx tree, so it’s impractical to replace their commit tx in the mempool). Nothing we can really do about that, other than some Core changes that need to happen regardless. So q: should we build anchor outputs where e.g. 1 utxo of anchor output reserve value, used for 4 channels’ force closes, do you spend that utxo to rbf bump all 4 chan force closes, or do something else? Alternative was 1 utxo per channel, which gets expensive. So now idea is, we’ll broadcast all 4 commit txs, then try to cpfp bump via spen all 4 of those with conflicting txs, goal is to get one of them confirmed (don’t care which) and we’ll rbf each as is required for each individual channel, hopefully one gets confirmed quickly, then we’ll have add’l utxos on-chain to go back and confirm those other 3 commits. This is antoine’s proposal; it’s a clever hack.

DLC/custom p2p messages

  • Tibo from crypto garage is working on it
    • Was gonna join this meeting but it’s a bad time for him
    • Maybe can have a separate meeting for him, he’s in Japan
  • Evan from sphinx: “this is super interesting to us. Esp if you can still do onion routing and propagate it across multiple hops.”
    • Evan interested in following along the discussion

Review begs

  • 3 issues tagged 0.0.11 that don’t yet have PRs
    • All pretty simple
    • Matt beg for corresponding PRs

Bindings

  • Nothing exciting recently
  • Arik working on a framework for it to work on OSX
  • Matt working on deterministic java bindings, might give up tho

Docs

  • Dennis working on migrating to Vue
  • Can still make changes rn, we have a separate develop branch for the new platform
  • We’ll transition when we’re ready for the look and feel
  • Jeff has a few PRs open
    • Val to review

RFCs

blip process

update closing_signed_fee requirement

channel types

Steve Qs

Laolu’s list of optimizations/lightning improvements from the ML that are “beyond the spec”

  • Steve to create a spreadsheet so we can make sure to cover all of their optimizations?
    • List sent to slack:
      1. keysend
      2. AMP
      3. hosted channels
      4. trampoline routing v1
      5. trampoline routing v2
      6. turbo channels
      7. podcast tipping protocol
      8. dual-funding
      9. on-demand channels
      10. sphinx chat messaging thing
      11. private routing as done by immortan
      12. alternative graph for unannounced channels as done by immortan
      13. lnurl-withdraw
      14. lnurl-pay
      15. lnurl-channel
      16. bitcoin-liquid lightning bridge
      17. I thought I had more but apparently I forgot
Clone this wiki locally