475a77219a6e7649c91b7cfeb44871cee9d0f374 refactor(bdk)!: Remove trait Vbytes (vmammal) 0d64beb040e885d653adb901dc49482f9daafddf chore: organize some imports (vmammal) 89608ddd0fd582d011f7b7ae8bbeb63dee6a3b99 refactor(bdk): display CreateTxError::FeeRateTooLow in sat/vb (vmammal) 09bd86e2d82020d5f4079c5d234888a9eed50489 test(bdk): initialize all feerates from `u64` (vmammal) 004957dc2969171b7a37ce92d2cdb0e8f22b6da5 refactor(bdk)!: drop FeeRate from bdk::types (vmammal) Pull request description: ### Description This follows a similar approach to #1141 namely to remove `FeeRate` from `bdk::types` and instead defer to the upstream implementation for all fee rates. The idea is that making the switch allows BDK to benefit from a higher level abstraction, leaving the implementation details largely hidden. As noted in #774, we should avoid extraneous conversions that can result in deviations in estimated transaction size and calculated fee amounts, etc. This would happen for example whenever calling a method like `FeeRate::to_sat_per_vb_ceil`. The only exception I would make is if we must return a fee rate error to the user, we might prefer to display it in the more familiar sats/vb, but this would only be useful if the rate can be expressed as a float. ### Notes to the reviewers `bitcoin::FeeRate` is an integer whose native unit is sats per kilo-weight unit. In order to facilitate the change, a helper method `feerate_unchecked` is added and used only in wallet tests and psbt tests as necessary to convert existing fee rates to the new type. It's "unchecked" in the sense that we're not checking for integer overflow, because it's assumed we're passing a valid fee rate in a unit test. Potential follow-ups can include: - [x] Constructing a proper `FeeRate` from a `u64` in all unit tests, and thus obviating the need for the helper `feerate_unchecked` going forward. - [x] Remove trait `Vbytes`. - Consider adding an extra check that the argument to `TxBuilder::drain_to` is within "standard" size limits. - Consider refactoring `coin_selection::select_sorted_utxos` to be efficient and readable. closes #1136 ### Changelog notice - Removed `FeeRate` type. All fee rates are now rust-bitcoin [`FeeRate`](https://docs.rs/bitcoin/latest/bitcoin/blockdata/fee_rate/struct.FeeRate.html). - Removed trait `Vbytes`. ### 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 ACKs for top commit: evanlinjin: ACK 475a77219a6e7649c91b7cfeb44871cee9d0f374 Tree-SHA512: 511dab8aa7a65d2b15b160cb4feb96964e8401bb04cda4ef0f0244524bf23a575b3739783a14b90d2dccc984b3f30f5dabfb0a890ffe7c897c2dc23ba301bcaf
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:
bdk
: 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 datafile_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 bdkWallet
.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
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
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
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:
# 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
- 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.