LocalChain with hardwired genesis block
f1b112e8f9docs(bitcoind_rpc): update docs for `Emitter::new` (志宇)9a250baf62chore: make clippy happy (志宇)79b84bed0efeat(bdk): changeset's `Append` impl checks that network is consistent (志宇)06a956ad20feat!: change `load_from_persistence` to return an option (志宇)c3265e2514test(bdk): add tests for wallet constructor methods (志宇)96f1d94e2ctest(file_store): add construction method tests (志宇)1886dc4fe7chore(examples): use `Wallet::new_or_load` method where appropriate (志宇)24994a3ed4feat(file_store)!: have separate methods for creating and opening Store (志宇)d294e2e318feat(wallet)!: add `new_or_load` methods (志宇)7c6cbc4d9fchore(file_store): rm empty test file (志宇)6cf3963c6cfeat(bdk)!: have separate methods for creating and loading `Wallet` (志宇)7d5f31f6ccfeat(chain, file_store): add `is_empty` method to `PersistBackend` trait (志宇)5998a22819feat!: `LocalChain` with hardwired genesis checkpoint (志宇) Pull request description: closes #1079 closes #1107 ### Description Many methods of `TxGraph` require a `chain_tip: BlockId` input to use against a `ChainOracle` implementation. This is used to ask the `ChainOracle` implementation whether a certain block exists in the chain identified by the `chain_tip`. This guarantees that the `TxGraph` methods will return a consistent history of transactions. However, the `ChainOracle` trait's `get_chain_tip` method returns an option of `BlockId`. It becomes unclear what to do when `get_chain_tip` returns `None`. This PR changes the `ChainOracle::get_chain_tip` method to always return a `BlockId` (no `Option`). `LocalChain` now hardwires the genesis block in order to implement `ChainOracle`. `bdk::Wallet` and `bdk_file_store::Store` are changed to have separate constructor methods for initializing a fresh instance and recovering a previous instance from persistence. ### Notes to the reviewers ### Changelog notice - Changed `ChainOracle::get_chain_tip` method to return a `BlockId` instead of an `Option` of a `BlockId`. - Refactored `LocalChain` so that the genesis `BlockId` is hardwired. This way, the `ChainOracle::get_chain_tip` implementation can always return a tip. - Add `is_empty` method to `PersistBackend`. This returns true when there is no data in the persistence. - Changed `Wallet::new` to initialize a fresh wallet only. - Added `Wallet::load` to restore an instance of a wallet. - Replaced `Store::new` with separate methods to create/open the database file. ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing #### New Features: * [x] I've added tests for the new feature * [x] I've added docs for the new feature Top commit has no ACKs. Tree-SHA512: 31b75fb53cc451f1fce7e409f1112c43973db7e8b5b31640e01e5b52089683b60320565427d6ea0478ff4c8680dbdb9272fdab08aef69d30f257da52e731e1a3
The Bitcoin Dev Kit
BDK
A modern, lightweight, descriptor-based wallet library written in Rust!
Project Homepage | Documentation
About
The bdk libraries aims to provide well engineered and reviewed components for Bitcoin based applications.
It is built upon the excellent rust-bitcoin and rust-miniscript crates.
⚠ The Bitcoin Dev Kit developers are in the process of releasing a
v1.0which is a fundamental re-write of how the library works. See for some background on this project: https://bitcoindevkit.org/blog/road-to-bdk-1/ (ignore the timeline 😁) For a release timeline see theBDK 1.0 project page.
Architecture
The project is split up into several crates in the /crates directory:
bdk: Contains the central high levelWallettype that is built from the low-level mechanisms provided by the other componentschain: Tools for storing and indexing chain datafile_store: A (experimental) persistence backend for storing chain data in a single file.esplora: Extends theesplora-clientcrate with methods to fetch chain data from an esplora HTTP server in the form thatbdk_chainandWalletcan consume.electrum: Extends theelectrum-clientcrate with methods to fetch chain data from an electrum server in the form thatbdk_chainandWalletcan consume.
Fully working examples of how to use these components are in /example-crates:
example_cli: Library used by theexample_*crates. Provides utilities for syncing, showing the balance, generating addresses and creating transactions without using the bdkWallet.example_electrum: A command line Bitcoin wallet application built on top ofexample_cliand theelectrumcrate. It shows the power of the bdk tools (chain+file_store+electrum), without depending on the mainbdklibrary.wallet_esplora_blocking: Uses theWalletto sync and spend using the Esplora blocking interface.wallet_esplora_async: Uses theWalletto sync and spend using the Esplora asynchronous interface.wallet_electrum: Uses theWalletto sync and spend using Electrum.
Minimum Supported Rust Version (MSRV)
This library should compile with any combination of features with Rust 1.57.0.
To build with the MSRV you will need to pin dependencies as follows:
# log 0.4.19 has MSRV 1.60.0+
cargo update -p log --precise "0.4.18"
# tempfile 3.7.0 has MSRV 1.63.0+
cargo update -p tempfile --precise "3.6.0"
# rustls 0.21.7 has MSRV 1.60.0+
cargo update -p rustls:0.21.8 --precise "0.21.1"
# rustls 0.20.9 has MSRV 1.60.0+
cargo update -p rustls:0.20.9 --precise "0.20.8"
# tokio 1.33 has MSRV 1.63.0+
cargo update -p tokio --precise "1.29.1"
# tokio-util 0.7.9 doesn't build with MSRV 1.57.0
cargo update -p tokio-util --precise "0.7.8"
# flate2 1.0.27 has MSRV 1.63.0+
cargo update -p flate2 --precise "1.0.26"
# reqwest 0.11.19 has MSRV 1.63.0+
cargo update -p reqwest --precise "0.11.18"
# h2 0.3.21 has MSRV 1.63.0+
cargo update -p h2 --precise "0.3.20"
# rustls-webpki 0.100.3 has MSRV 1.60.0+
cargo update -p rustls-webpki:0.100.3 --precise "0.100.1"
# rustls-webpki 0.101.2 has MSRV 1.60.0+
cargo update -p rustls-webpki:0.101.7 --precise "0.101.1"
# zip 0.6.6 has MSRV 1.59.0+
cargo update -p zip --precise "0.6.2"
# time 0.3.14 has MSRV 1.59.0+
cargo update -p time --precise "0.3.13"
# byteorder 1.5.0 has MSRV 1.60.0+
cargo update -p byteorder --precise "1.4.3"
# webpki 0.22.4 requires `ring:0.17.2` which has MSRV 1.61.0+
cargo update -p webpki --precise "0.22.2"
# os_str_bytes 6.6.0 has MSRV 1.61.0+
cargo update -p os_str_bytes --precise 6.5.1
# sct 0.7.1 has MSRV 1.61.0+
cargo update -p sct --precise 0.7.0
# cc 1.0.82 has MSRV 1.61.0+
cargo update -p cc --precise "1.0.81"
# jobserver 0.1.27 has MSRV 1.66.0+
cargo update -p jobserver --precise "0.1.26"
License
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.