8dd174479f9719309663ed979a5b4b86aca0a6e9 refactor(chain): compute txid once for `KeychainTxOutIndex::index_tx` (志宇) 639d735ca0ae54d8b2c3bc28241032154b94d45e refactor(chain): change field names to be more sane (志宇) 5a02f40122f1bfa06c80bac93f68f5799225d133 docs(chain): fix docs (志宇) c77e12bae7f465ec7fb08b8be16d99793c757cf0 refactor(chain): `KeychainTxOutIndex` use `HashMap` for fields (志宇) 4d3846abf4f59b4a97bb825281655a6b67275603 chore(chain): s/replenish_lookahead/replenish_inner_index/ (LLFourn) 8779afdb0bf4e9b1004f47f86a770d25938d206d chore(chain): document insert_descriptor invariants better (LLFourn) 69f2a695f7dc25478489080598fea0813ea7d93d refactor(chain): improve replenish lookeahd internals (LLFourn) 5a584d0fd8c138757a10c7af93ec9e09523317e1 chore(chain): Fix Indexed and KeychainIndexed documentaion (Lloyd Fournier) b8ba5a02066fad7ab2ce276ba071385cd1dbbe3a chore(chain): Improve documentation of keychain::ChangeSet (LLFourn) 101a09a97fa5e8d675c13396b9a800665b1b6c22 chore(chain): Standardise KeychainTxOutIndex return types (LLFourn) bce070b1d662db7ac120e1d236fdda51842ad738 chore(chain): add type IndexSpk, fix clippy type complexity warning (Steve Myers) 4d2442c37f5c1bd822795271a79676d1ffbe7916 chore(chain): misc docs and insert_descriptor fixes (LLFourn) bc2a8be97919f0d09b61438527bda24796bcec94 refactor(keychain): Fix KeychainTxOutIndex range queries (LLFourn) 3b2ff0cc953204c9925ace8e2f0bbef409c63ad5 Write failing test for keychain range querying (LLFourn) Pull request description: Fixes #1459 This reverts part of the changes in #1203. There the `SpkTxOutIndex<(K,u32)>` was changed to `SpkTxOutIndex<(DescriptorId, u32>)`. This led to a complicated translation logic in `KeychainTxOutIndex` (where the API is based on `K`) to transform calls to it to calls to the underlying `SpkTxOutIndex` (which now indexes by `DescriptorId`). The translation layer was broken when it came to translating range queries from the `KeychainTxOutIndex`. My solution was just to revert this part of the change and remove the need for a translation layer (almost) altogether. A thin translation layer remains to ensure that un-revealed spks are filtered out before being returned from the `KeychainTxOutIndex` methods. I feel like this PR could be extended to include a bunch of ergonomics improvements that are easier to implement now. But I think that's the point of https://github.com/bitcoindevkit/bdk/pull/1451 so I held off and should probably go and scope creep that one instead. ### 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 #### Bugfixes: * [x] This pull request breaks the existing API * [x] I've added tests to reproduce the issue which are now passing * [x] I'm linking the issue being fixed by this PR ACKs for top commit: evanlinjin: ACK 8dd174479f9719309663ed979a5b4b86aca0a6e9 Tree-SHA512: 283e6b6d4218902298e2e848fe847a6c85e27af4eee3e4337e3dad6eacf9beaa08ac99b1dce7b6fb199ca53931e543ea365728a81c41567a2e510cce77b12ac0
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.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 theBDK 1.0 project page
.
Architecture
The project is split up into several crates in the /crates
directory:
wallet
: Contains the central high levelWallet
type that is built from the low-level mechanisms provided by the other componentschain
: Tools for storing and indexing chain datapersist
: Types that define data persistence of a BDK walletfile_store
: A (experimental) persistence backend for storing chain data in a single file.esplora
: Extends theesplora-client
crate with methods to fetch chain data from an esplora HTTP server in the form thatbdk_chain
andWallet
can consume.electrum
: Extends theelectrum-client
crate with methods to fetch chain data from an electrum server in the form thatbdk_chain
andWallet
can 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 bdk_walletWallet
.example_electrum
: A command line Bitcoin wallet application built on top ofexample_cli
and theelectrum
crate. It shows the power of the bdk tools (chain
+file_store
+electrum
), without depending on the mainbdk_wallet
library.example_esplora
: A command line Bitcoin wallet application built on top ofexample_cli
and theesplora
crate. It shows the power of the bdk tools (chain
+file_store
+esplora
), without depending on the mainbdk_wallet
library.example_bitcoind_rpc_polling
: A command line Bitcoin wallet application built on top ofexample_cli
and thebitcoind_rpc
crate. It shows the power of the bdk tools (chain
+file_store
+bitcoind_rpc
), without depending on the mainbdk_wallet
library.wallet_esplora_blocking
: Uses theWallet
to sync and spend using the Esplora blocking interface.wallet_esplora_async
: Uses theWallet
to sync and spend using the Esplora asynchronous interface.wallet_electrum
: Uses theWallet
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:
cargo update -p zstd-sys --precise "2.0.8+zstd.1.5.5"
cargo update -p time --precise "0.3.20"
cargo update -p home --precise "0.5.5"
cargo update -p proptest --precise "1.2.0"
cargo update -p url --precise "2.5.0"
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.