search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.14k stars 358 forks source link

Meeting Minutes #717

Closed ariard closed 2 years ago

ariard commented 3 years ago

_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

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

Chair: @ariard

Agenda:

ariard commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

2020-11-30

Attendees

Ongoing work (high-priority pending reviews bold)

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

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 commented 2 years ago

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