1 Meeting Notes 2021 12 13

Elias Rohrer edited this page 2022-08-09 11:03:08 +02:00

Unescape Escape

Table of Contents

• Releases
• Java
• DLCs
• Spec
• Signer support
• Review begs
• LDK Community:
• Lightning
• Graph sync
• Misc

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.

• Welcome duncan!
  • Duncan: been poking around ldk, seeing where i can get involved, nothing major atm

Releases

• 0.0.104

  • #1202 payment retries
    • Shaping up
  • #1212 pruning network graph
    • Trivial
  • #1177? Stop storing pending inbound pmt data
    • Close, matt needs to review + jeff to fully grok payment secret construction
    • Val to squash
  • Probabilistic scoring unlikely to get in
    • Tricky with direction and decays, there’s way to do it simply but need channel capacity, and there’s an edge case(s) there too with that
  • ETA asap
    • If it slips past the next 2-3 days, not gonna happen before holidays

• 0.1

  • #1056 auto close after some time if counterparty doesn’t accept a fee update
    • There’s a follow up issue for ariard previous PR #1054 too
      • Ariard: prob will do follow up later
    • Issue: what should be the units of the timer? How does it work? Block frequency or just a timer tick?
    • Ariard wants it to be based on the timer, not block, which means it needs to happen in the Channel not monitor (which only has blocks, not time). Matt wants block
    • Matt: Issue: by the time we detect a stale feerate, it’s almost certainly too late to get into the next block. So we might as well wait til we hit a block_connected, which would allow simplifying the code a lot
    • If our peer doesn’t answer, and feerates are going up, then trying to get into the next block is not gonna happen, and we’ll just wait to get into one of the next few blocks
  • #1106
  • Ton of issues

Java

• Matt: theres some interaction in openjdk 11, current stable version, where java will call finalize() -- basically garbage collector decides it’s unreachable when it’s clearly reachable. Like we’re calling a method on an object and java will just free it in the middle -- use-after-free bug when using jni code.
  • Poked at it from every possible direction, only workaround so far is to turn off the JIT
  • Doesn’t seem to be anything we can do besides some kind of delay where anytime we get finalize we wait 5 seconds before actually doing it, and hope that that’s enough time
  • Galderz may actually be on the openjdk team, but on paternity leave, so trying to contact him and talk to square/block support contract with redhat or somebody since they have a lotta java code. Trying to access that and file a bug w/ them (redhat presumably) to force someone to take a look
  • For now, turn off the JIT (not confident in this tho, just have yet to see it crash with -Xint which turns off the JIT)
• Matt: think JNI is not very used anymore, so think it might be sth to do with that

DLCs

• Ariard to answer tibo on mailing list
• https://mailmanlists.org/pipermail/dlc-dev/2021-November/000091.html and https://github.com/Tibo-lg/lightning-rfc/pull/1/files

Spec

• Nothing new here
• payment

Signer support

• Ken: been feeding upstream PRs to c-lightning so they support the apis we need. Maybe halfway there. There’s two in the queue now and we prob need another 3 to complete that.
• They’ve been receptive + reviewing/resolving issues that come up quickly
• Devrandom: they were quiet for a while then suddenly a lot of activity from rusty
• Nothing needed rn for ldk side
• Devrandom: been mostly improving the lnrod sample node impl (by cribbing from LDK sample) and running it in testnet against matt’s and conor’s nodes. Working well, gonna try mainnet next

Review begs

• Matt has a sample PR
• Conor mentioned #99 for the website

LDK Community:

• public board for feature request/milestones tracking, see https://lightningdevkit.slack.com/archives/CSYT185MY/p1637600110131600

Lightning

• payment metadata
• BLIPs : https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003401.html
• route blinding
  • Basically part of trampoline, the part where the “receiver” can decide on more hops from a certain point
• channel reestablish
  • If someone sends CE, and proves they’re behind, tbast suggested it’d be nice if we didn’t force close, and just sent an error, and it’s up to the node that’s behind to try to …
• simplified update
  • Simplifies stuff nicely but don’t need to spend time on it rn
• PTLCs early draft specification : https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003377.html

Graph sync

• Arik: been making big strides, mostly made it more parallelizable to retrieve data from the gossip protocol and then persist it in postgres, so i have noticed that as you ask for data from gossip a peer node, there are a bunch of dup chan updates, de-duping yields 67% improvement. But that’s mostly an artifact of gossip protocol partitioning their updates into separate msgs, when you try to do sth more sophisticated like asking for updates after a certain timestamp, and then which are the per-direction updates for those same channels, and want to run a comparison to verify whether anything has changed s.t. If not you could omit the update, there is no overlap that i have seen so far. May be bc big batch of updates that were repeating, and as i’m running the update persistence process and getting fresher updates, maybe ill be able to produce a higher compression. But i haven’t seen multiple updates per channel, only same update being copied across diff gossip msgs, little annoying.

Misc

• Ariard
  • If someone can take back the agenda making, im gonna put ldk in the background in the coming months
  • Jkczyz: i can do it