Meeting Minutes

[ariard]

Please don't comment on this issue beyond proposing future meeting topics. If you have suggestion make them directly on the LDK slack #ldk-dev

LDK roadmap : https://docs.google.com/document/d/1VunFXeYlRICTO4DHK9oPy7NM4m2ikVvHzph2Toq890w/edit#heading=h.sxl6s6jiei00

Meeting each other Monday when the LN dev doesn't happen.

Next Meeting : 28/12/2020 19:00 UTC LDK slack #ldk-dev

Chair: @devrandom

• 0.0.13 reviews (Introduce CommitmentTransactionInfo #742/ChannelManager persistence #752/MPP on the router side #646/Add a new method read_chan_signer to KeysInterface #761/Don't include below-dust inbound HTLCs in commit tx fee calculation #762)
  • is Introduce CommitmentTransactionInfo #742 in 0.0.13?
• node sample (Lightning block sync and sample block sources #763, other pieces?)
• collaboration tooling - move meeting agenda / notes to a wiki?
• user journeys - I see the doc has a single journey (dev eval journey) - is there more needed for now?
• what are our goals for PR turnaround? last meeting people seemed optimistic that things are improving, but @devrandom is a bit concerned again

Previous Meeting : 14/12/2020 19:00 UTC LDK slack #ldk-dev

Chair: @ariard

Agenda:

• 0.0.13 reviews (Introduce CommitmentTransactionInfo #742/ChannelManager persistence #752/Initiate gossip_queries #736/MPP on the router side #646)
• user journeys
• merge rights infrastructure
• node sample
• spec update (new commitment format option_zero_htlc_tx_fee, zlib support, sync complete)
• dev onboarding : a glossary

[ariard]

09/21/2020

Participants

arik-so
naumenkogs
devrandom
TheBlueMatt
ariard
valentinewallace
jkczyz

Ongoing Work

ChannelData Persister PR (#681)
ChainMonitor Refactoring PR (#649)
Bug framework fix PR (#715)
MPP Routing (#646)
Anchor output implementation
React Native Integration of the LDK
NOISE State Machine (#691)
PeerManager (#692)
ChannelKeys interface - tx specification
Lightning-signer API bump

Long-term discussions

Distributed channel monitors state synchronization w.r.t to channel state, bumping utxo set and key material.
Question : "right, I'm primarily curious about whether bumping utxo assignment is based purely on rules, and not on key material? And if so, how can you make sure that announcement of those rules is synced across monitors? (we can continue out of band)"

Sample node similar to rust-lightning-bitcoinrpc pending on #614 (lightning-block-sync). Goal a "LDK example usage (modular, well tested and documented)"

High-level API freeze once we have a baselines for usability, including language bindings. Pending on previous point which is getting sample of interfaces.

Security review and codebase audit.

Review Process

Problem : It's hard to know quickly the state of a PR. Better labeling on PR-Waiting-Author and PR-Waiting-Reviewer.

Number of ACKs in function of PRs complexity.

Transitioning toward a small PRs approach.

Top-of-stack Reviews

715 -> 649 -> 681
691 ; 646 ; 692

[ariard]

05/10/2020

Participants

arik-so
naumenkogs
devrandom
TheBlueMatt
ariard
valentinewallace
jkczyz
moneyball
sr-gi
Ken Sedgwick

Ongoing Work

ChannelData Persister (#681)
Signer "phase 2" API (#723)
LDK java bindings
LDK wasm bindings
Lightning-signer reference implemention
MPP Routing (#646)
Anchor outputs (#642/#725/#726)

Discussions

naumenkogs is looking to work on channel scoring/autopilot post MPP. Before doing any automatic channel management, basic data tracking about channels is necessary (uptime, flapiness, profitibality, activity, peer, balance, volume, channel age)

Refactoring HolderCommitmentTransaction, only storing new/per-tx data in this struct, as motivated by devrandom work around signer API modifications.

Finalizing the 0.0.12 release (https://github.com/rust-bitcoin/rust-lightning/milestone/11), mostly landing #681 and few other bug fixes.

A sample node with the following components is the highest priority: chain data, on-chain UTXO management, on-chain transaction broadcasting, storage mapping, networking mapping, source of randomness, LN routing, fee-estimation.

moneyball proposed the following LDK dev onboarding process :

1. "download" the LDK
2. follow the readme to build and run the sample node (bonus: have eye of satoshi watchtower running too)
3. browse the sample code to understand how it works
4. read dev docs to understand how it works
5. bonus: example code written in swift, javascript, java
6. start modifying and tinkering
7. integrate with an existing wallet for proof of concept

It sounds like potential users prefer good demo code over exhaustive manual. A walking through tutorial Learn LDK has been proposed by jczyz. TheBlueMatt underscored the needs for better module-level docs. Graphical representations like diagrams should also be added (Ken Sedgwick suggestion about diagrams.net)

Top-of-stack Reviews

681 ; 653 ; 646

[ariard]

19/10/2020

Participants

arik-so
TheBlueMatt
ariard
devrandom
valentinewallace
jkczyz
moneyball
sr-gi
LLFourn

Ongoing Work

Signer "phase 2" API (#723/#742)
LDK java bindings
LDK wasm bindings
Offchain-to-onchain preimage claiming (#611)

Discussions

Dropping #575, a spec update would be better instead of a non-announced channel policy variable.

Ongoing spec discussions around channel jamming. Big spec update has been quite stale due to a lack of coordination on hard-topics between devs teams. Hopefully adopting a better process by archiving discussions in one place (lightning-docs).

The Sample Node : a piecemeal part of the dev onboarding process is a showcase simple node, ready-to-be-forked by application developers to learn about library architecture. It should be easy to maintain it and serve also a testing tool for RL devs. Needs to take (#614) as dependency.

To support LN packets experimentation (PTLC/DLC), RL internal transactions handling should be refactored. Hopefully, as these refactoring are needed long-term for Schnorr support they should be kept in-tree.

As a general point, opening PRs first as a draft is recommended.

Top-of-Stack Reviews

611
742 -> 723
646
736

[ariard]

16/11/2020

Participants

arik-so
TheBlueMatt
ariard
moneyball
devrandom
valentinewallace
jkczyz

Ongoing work

MPP (#563)
Fuzzer updates
lightning-block-source
ldk-nodejs code generation
Signer "phase 2" API (#742)
node-sample
lightning-persister

Discussions

0.0.12 is almost done, the last piece to land is valentinewallace's #611 and TheBlueMatt's #749.

There is a pending debate on #742 on a "functional-vs-oop" to isolate cleanly onchain transactions naming ("broadcaster/countersignatory") from offchain channel directions ("holder/counterparty"). TheBlueMatt favors a functional approach. ariard a functional one after PR discussions with devrandom. The debate is left to be solved after a review round on the PR by TheBlueMatt.

TheBlueMatt would like to explore symbolic execution fuzzing in the future. Also noting on mutation testing " mutagen isn't a fan of the idea of exiting with a failure if there is missing coverage instead noting that mutation is really a coverage generator not so much a unit test generator...which is fair, but I'm not aware of any way to get mutagen output to show up in codecov or so." (TheBlueMatt).

The next step after node-sample workable and language bindings is to write down "look how everything you can do with LDK" dev docs. jkczyz pointed it would be good to agree first on information hierarchical outline, identifying user journeys and focus on critical ones.

Folks somehow agree that a 0.0.13 should incorporate gossips and MPP.

devrandom and ariard discussed about the next key-management steps. One unsolved question is about the bumping utxo anchor output API if it should be a layer-1 operation (outside the keyinterface) or a layer-2 one. Maybe "Don't sign this CPFP for this commitment because HTLC aren't economically interesting" policy would make sense to make bumping utxo signing a layer-2 operation. A clean separation between layer-1/layer-2 operation in itself is a good question.

On persistence, valentincewallace is working on a channelmanager PR. Upcoming, are route graph persistence, see #752 for tracking.

It turns out the team had issues coordinating on complex topics (i.e generic channels, autopilot infrastructure, ...) . Sharing projects rights to everyone might be a solution with informal owner could be great.

Specification Discussions

Fee leak
Offers
Route blinding

Action items

Coming up with your nice "what-to-build-with-LDK" ideas for the next meeting.
Sharing backlogs yet-to-be-done to give visibility to others.

Top-of-Stack Reviews

646
611
742

[arik-so]

2020-11-30

Attendees

• ariard
• gleb
• devrandom
• moneyball
• jkczyz
• sr-gi
• arik-so

Ongoing work (high-priority pending reviews bold)

• Signer API (Introduce CommitmentTransactionInfo #742)
• MPP (MPP on the router side #646)
• node-sample
• ChannelManager Persistence (ChannelManager persistence #752)
• Bindings
  • Python
  • WASM
• Graph fetching (Initiate gossip_queries #736)

Discussions

0.0.12 complete!

Functional vs OOP debate from #742 resolved in favor of OOP approach.

Gleb discussed two mitigation approaches for jamming attacks, one being paying fees up front, and the other comprising a cryptographic, privacy-preserving proof of UTXO ownership. Further discussion in the #security channel on the LDK Slack.

Feature set for 0.0.13 reprioritized to

• Fully functioning bindings (Add a new method read_chan_signer to KeysInterface #761)
• Persistence API (ChannelManager persistence #752)
• Route graph fetching (Initiate gossip_queries #736)

Clarification from jkczyz regarding user journeys, see action item.

Action items

Submit examplels of user journeys to issue opened by jkczyz (ID pending) by December 7th. Journey definition: a set of steps a user takes to complete a goal or accomplish a task, consisting of one goal and multiple roles, and focusing on intent as opposed to features.

[tnull]

Closing this since it hasn't been used for quite a while.