1 Meeting Notes 2021 07 12

Elias Rohrer edited this page 2022-08-09 10:32:28 +02:00

Unescape Escape

Table of Contents

• 0.0.99 report
• 0.0.100
• 0.1.0
• No_std
• Keysend
• Concurrent domino fee bumping #989
• DLC/custom p2p messages
• Review begs
• Bindings
• Docs
• 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”

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.

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

• new "zero-cost" onion messages : https://github.com/lightningnetwork/lightning-rfc/pull/759
  • Laolu may have an issue w/ forwarding messages for free
    • Proposed use case is to fetch invoices for rusty’s Offers thing
    • Matt: should be easy to rate-limit to get them to low cost, not worried

blip process

• https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003086.html
• Mailing list discussion for this
• Some bikeshedding about how to number the bLIPs
• Want to avoid collisions in feature bits and TLV types

update closing_signed_fee requirement

• https://github.com/lightningnetwork/lightning-rfc/pull/847
• Matt working on this as part of redoing whole closing fee pipeline, not much to discuss

channel types

• "take it or leave it": https://github.com/lightningnetwork/lightning-rfc/pull/880
• Channel type = negotiate whole set of channel feature bits atomically?

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