Meeting Minutes #717
Comments
09/21/2020Participantsarik-so Ongoing WorkChannelData Persister PR (#681) Long-term discussionsDistributed channel monitors state synchronization w.r.t to channel state, bumping utxo set and key material. 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 ProcessProblem : 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 Reviews715 -> 649 -> 681 |
05/10/2020Participantsarik-so Ongoing WorkChannelData Persister (#681) Discussionsnaumenkogs 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 :
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 Reviews681 ; 653 ; 646 |
19/10/2020Participantsarik-so Ongoing WorkSigner "phase 2" API (#723/#742) DiscussionsDropping #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 Reviews611 |
16/11/2020Participantsarik-so Ongoing workMPP (#563) Discussions0.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 DiscussionsFee leak Action itemsComing up with your nice "what-to-build-with-LDK" ideas for the next meeting. Top-of-Stack Reviews646 |
2020-11-30Attendees
Ongoing work (high-priority pending reviews bold)
Discussions0.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 itemsSubmit 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. |
|
Closing this since it hasn't been used for quite a while. |
and others
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
read_chan_signertoKeysInterface#761/Don't include below-dust inbound HTLCs in commit tx fee calculation #762)Previous Meeting : 14/12/2020 19:00 UTC LDK slack #ldk-dev
Chair: @ariard
Agenda:
option_zero_htlc_tx_fee, zlib support, sync complete)The text was updated successfully, but these errors were encountered: