志宇 53791eb6c5
Merge bitcoindevkit/bdk#1369: feat(chain): add get and range methods to CheckPoint
53942cced492138174638a8087b08f643a8d41ad chore(chain)!: rm `From<LocalChain> for BTreeMap<u32, BlockHash>` (志宇)
2d1d95a6850a5bab9c5bf369a498fe090852cd93 feat(chain): impl `PartialEq` on `CheckPoint` (志宇)
9a62d56900a33a519dd0165ccdb91711917772f3 feat(chain): add `get` and `range` methods to `CheckPoint` (志宇)

Pull request description:

  Partially fixes #1354

  ### Description

  These methods allow us to query for checkpoints contained within the linked list by height and height range. This is useful to determine checkpoints to fetch for chain sources without having to refer back to the `LocalChain`.

  Currently this is not implemented efficiently, but in the future, we will change `CheckPoint` to use a skip list structure.

  ### Notes to the reviewers

  Please refer to the conversation in #1354 for more details. In summary, both `TxGraph::missing_heights` and `tx_graph::ChangeSet::missing_heights_from` are problematic in their own ways. Additionally, it's a better API for chain sources if we only need to lock our receiving structures twice (once to obtain initial state and once for applying the update). Instead of relying on methods such as `EsploraExt::update_local_chain` to get relevant checkpoints, we can use these query methods instead. This allows up to get rid of `::missing_heights`-esc methods and remove the need to lock receiving structures in the middle of the sync.

  ### Changelog notice

  * Added `get` and `range` methods to `CheckPoint` (and in turn, `LocalChain`). This simulates an API where we have implemented a skip list of checkpoints (to implement in the future). This is a better API because we can query for any height or height range with just a checkpoint tip instead of relying on a separate checkpoint index (which needs to live in `LocalChain`).
  * Changed `LocalChain` to have a faster `Eq` implementation. We now maintain an xor value of all checkpoint block hashes. We compare this xor value to determine whether two chains are equal.
  * Added `PartialEq` implementation for `CheckPoint` and `local_chain::Update`.

  ### 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

ACKs for top commit:
  LLFourn:
    ACK 53942cced492138174638a8087b08f643a8d41ad

Tree-SHA512: 90ef8047fe1265daa54c9dfe8a8c520685c898a50d18efd6e803707fcb529d0790d20373c9e439b9c7ff301db32b47453020cae7db4da2ea64eba895aa047f30
2024-04-06 10:23:46 +08:00
2023-02-13 11:38:26 -06:00
2024-02-04 06:13:40 -03:00
2023-11-16 07:25:20 -06:00
2023-11-16 07:25:20 -06:00
2023-09-16 10:43:26 -05:00
2024-01-22 08:08:24 -03:00

The Bitcoin Dev Kit

BDK

A modern, lightweight, descriptor-based wallet library written in Rust!

Crate Info MIT or Apache-2.0 Licensed CI Status API Docs Rustc Version 1.63.0+ Chat on Discord

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.0 which 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 the BDK 1.0 project page.

Architecture

The project is split up into several crates in the /crates directory:

  • bdk: Contains the central high level Wallet type that is built from the low-level mechanisms provided by the other components
  • chain: Tools for storing and indexing chain data
  • file_store: A (experimental) persistence backend for storing chain data in a single file.
  • esplora: Extends the esplora-client crate with methods to fetch chain data from an esplora HTTP server in the form that bdk_chain and Wallet can consume.
  • electrum: Extends the electrum-client crate with methods to fetch chain data from an electrum server in the form that bdk_chain and Wallet can consume.

Fully working examples of how to use these components are in /example-crates:

  • example_cli: Library used by the example_* crates. Provides utilities for syncing, showing the balance, generating addresses and creating transactions without using the bdk Wallet.
  • example_electrum: A command line Bitcoin wallet application built on top of example_cli and the electrum crate. It shows the power of the bdk tools (chain + file_store + electrum), without depending on the main bdk library.
  • example_esplora: A command line Bitcoin wallet application built on top of example_cli and the esplora crate. It shows the power of the bdk tools (chain + file_store + esplora), without depending on the main bdk library.
  • example_bitcoind_rpc_polling: A command line Bitcoin wallet application built on top of example_cli and the bitcoind_rpc crate. It shows the power of the bdk tools (chain + file_store + bitcoind_rpc), without depending on the main bdk library.
  • wallet_esplora_blocking: Uses the Wallet to sync and spend using the Esplora blocking interface.
  • wallet_esplora_async: Uses the Wallet to sync and spend using the Esplora asynchronous interface.
  • wallet_electrum: Uses the Wallet to sync and spend using Electrum.

Minimum Supported Rust Version (MSRV)

This library should compile with any combination of features with Rust 1.63.0.

To build with the MSRV you will need to pin dependencies as follows:

# zip 0.6.3 has MSRV 1.64.0
cargo update -p zip --precise "0.6.2"
# time 0.3.21 has MSRV 1.65.0
cargo update -p time --precise "0.3.20"
# jobserver 0.1.27 has MSRV 1.66.0
cargo update -p jobserver --precise "0.1.26"
# home 0.5.9 has MSRV 1.70.0
cargo update -p home --precise "0.5.5"

License

Licensed under either of

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.

Languages
Rust 99.9%