Steve Myers

@afilini I recall you also ran into some `no_std` binary size issues but I can't find that issue. Did you make any discoveries that could help? I seem to recall...

Current code test coverage is good, see current CodeCov stats below. | crate | Line Coverage | Functions | |-------|---------------|-----------| | bitcoind_rpc | 81.6 % , 129 / 158 |...

You mean exclude examples from `cargo check`? I think the only reason we exclude them in CI was to avoid MSRV dependency issues, but for this `Justfile` it shouldn't be...

~~Since this is currently based on the `master` branch should we re-assign this to the 3.0 milestone and then do a new PR to back port it to 2.2?~~ Nevermind,...

cACK, but haven't done a close review yet. Thanks for hanging in on this one, but looks like it needs another rebase.

@tnull & @binarybaron what would you think about extracting the `bdk_sqlite` persistence store from the `bdk_chain` crate and putting it in it's own crate. If we do that we could...

@LLFourn what if we use the RPC syncing as it is now but with a bitcoind node set to ["manual" pruning](https://github.com/bitcoin/bitcoin/pull/7871)? then we just have to add functionality to call...

Removing from 1.1 milestone since no PR ready.

I suspect the way to start syncing from a birthday block would be to use [Wallet::apply_block_connected_to()](https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.Wallet.html#method.apply_block_connected_to) with params birthday_block, birthday_block_height, genesis_block_id. But I haven't tried it so I could be...

Another data-point, using a modified unit test from bitcoindevkit/bdk_wallet#336 I was able to apply a new block with a gap between it and the genesis block and got the expected...