Upstream VssStoreBuilder and VssStore to lightning-persister#4323
Upstream VssStoreBuilder and VssStore to lightning-persister#4323tnull wants to merge 2 commits intolightningdevkit:mainfrom
VssStoreBuilder and VssStore to lightning-persister#4323Conversation
|
👋 Hi! This PR is now in draft status. |
Since the beginning of VSS we intended to upstream the corresponding `KVStore` implementation to `lightning-persister`. Here, we finally do it. Signed-off-by: Elias Rohrer <dev@tnull.de>
ae47ff5 to
0817a96
Compare
Signed-off-by: Elias Rohrer <dev@tnull.de>
0817a96 to
2e8b7cd
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4323 +/- ##
=======================================
Coverage 86.61% 86.62%
=======================================
Files 158 158
Lines 102730 102730
Branches 102730 102730
=======================================
+ Hits 88984 88988 +4
+ Misses 11328 11326 -2
+ Partials 2418 2416 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| } | ||
| } | ||
|
|
||
| /// A source for generating entropy/randomness using [`rand`]. |
There was a problem hiding this comment.
Shouldn't we either require one be provided or use lightning::sign::RandomBytes?
Somewhat unrelatedly its never really been clear to me why we use rand for anything - all it is is the getrandom crate plus chacha20, why aren't we using the chacha20 we have plus getrandom instead of rand?
The former is done here lightningdevkit/vss-client#56, for |
Since the beginning of VSS we intended to upstream the corresponding
KVStoreimplementation tolightning-persister.Here, we finally do it. I'll put this in draft until lightningdevkit/ldk-node#755 lands so we can directly upstream the version already upgraded for pubkey-auth.