Uh oh!
There was an error while loading. Please reload this page.
Add subcrate which impls a simple SPV client from Bitcoin Core RPC - #614
Add subcrate which impls a simple SPV client from Bitcoin Core RPC#614TheBlueMatt wants to merge 2 commits into
Conversation
aae0859 to
8fcb6e1CompareThese are essentially required to make rescan-at-reload doable as individual ChannelMonitors may be synced to different chain states and thus need to have blocks replayed separately.
b0319cd to
c872ef4CompareTheBlueMatt
commented
May 2, 2020
Still a bit raw in terms of code quality and still need testing, but its a thing, and worth at least a glance-over. |
a5f78fc to
a61c2cbCompareCodecov Report
@@ Coverage Diff @@## master #614 +/- ##
==========================================
- Coverage 91.12% 91.11% -0.01%
==========================================
Files 34 34 Lines 20544 20544 ==========================================
- Hits 18720 18719 -1 - Misses 1824 1825 +1
Continue to review full report at Codecov.
|
0861e43 to
23368f5CompareThis adds a new subcrate `lightning-block-sync` which is designed to make it easier to get up-and-running by removing the effort of building an SPV client and fetching the chain. Instead of building a P2P client (and all the address management that entails), this focuses on building a trivial SPV client which can fetch from several instances of an abstract BlockSource. Then, we provide two example BlockSource implementations that can fetch from Bitcoin Core's RPC interface and Bitcoin Core's REST interface. The code here is taken with heavy modifications from rust-lightning-bitcoinrpc.
23368f5 to
197e244Compare
valentinewallace
left a comment
There was a problem hiding this comment.
Haven't dived into the details yet but overall the structure looks good and makes sense!
I think the commits could be split up a bit more though. If you're busy with language bindings I don't mind taking on this task. The following split makes sense to me, in order:
- common utilities used between REST client and RPC client
- the HTTP client
- the REST client (or swap 2 and 3, or possibly combine them)
- BlockSource + its implementors + the structs that only BlockSource/its implementors use
- The AChainListener + its implementors
- The MicroSPVClient and its static functions
valentinewallace
left a comment
There was a problem hiding this comment.
Also -- I think this could benefit from some example usage similar to what's in lightning-net-tokio: https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning-net-tokio/src/lib.rs#L17 through line 62.
TheBlueMatt
commented
May 22, 2020
@valentinewallace if you feel up to it feel free to take this over! Or @jkczyz if so inclined. |
jkczyz
commented
Jun 17, 2020
FYI, I've taken on this work and am currently working on some necessary refactoring to Regarding eec4beb, the refactoring mentioned above may alter this in some way. I'm looking into that now and will ping you with any questions that I may have. |
Here's the PR rebased on #649 using |
TheBlueMatt
commented
Dec 1, 2020
Superseded by #763. |
This is still very much a WIP, and I want to reduce the dependencies to at least not rely on hyper as well as actually implement the REST-based client, though doing so should be trivial.
This adds a new subcrate
lightning-http-blockswhich is designedto make it easier to get up-and-running by removing the effort of
building an SPV client and fetching the chain.
Instead of building a P2P client (and all the address management
that entails), this focuses on building a trivial SPV client which
can fetch from several instances of an abstract BlockSource. Then,
we provide two example BlockSource implementations that can fetch
from Bitcoin Core's RPC interface and Bitcoin Core's REST interface.
The code here is taken with heavy modifications from
rust-lightning-bitcoinrpc.
Addresses #627.