Steve Myers 0c8ee1dfe2
Merge bitcoindevkit/bdk#1514: refactor(wallet)!: rework persistence, changeset, and construction
64eb5763487df3c6cbb626e51f96ab6e47c5de22 chore(wallet): Fix ChangeSet::merge (LLFourn)
8875c92ec114ba9ca0ea8402d65d7a236566b618 chore(wallet): Fix descriptor mismatch error keychain (LLFourn)
2cf07d686b19787b5e97e0d5ed0b4cce7f56549f refactor(chain,wallet)!: move rusqlite things into it's own file (志宇)
93f9b83e275e8ab67630c925a39de6c01611a01b chore(chain): rm unused `sqlite` types (志宇)
892b97d4416d9d38ebf3d7e0c52636f110042302 feat(chain,wallet)!: Change persist-traits to be "safer" (志宇)
3aed4cf1798d7bd0189de315f5d7eacf212edb40 test(wallet): ensure checks work when loading wallet (志宇)
af4ee0fa4b82ddafa10c6b7fc35a2532351cd003 refactor(wallet)!: Make `bdk_wallet::ChangeSet` non-exhaustive (志宇)
22d02ed3d19e763d1ff54e3ec3657ed39c4ad66c feat!: improve wallet building methods (志宇)
eb73f0659e0046f39f5bf6a07d4145a19f865794 refactor!: move `WalletChangeSet` to `bdk_wallet` and fix import paths (志宇)
6b43001951db7738f788bcdbb46c8c1cd3e24a66 feat!: Rework sqlite, changesets, persistence and wallet-construction (志宇)

Pull request description:

  Closes #1496
  Closes #1498
  Closes #1500

  ### Description

  Rework sqlite: Instead of only supported one schema (defined in `bdk_sqlite`), we have a schema per changeset type for more flexiblity.

  * rm `bdk_sqlite` crate (as we don't need `bdk_sqlite::Store` anymore).
  * add `sqlite` feature on `bdk_chain` which adds methods on each changeset type for initializing tables, loading the changeset and writing.

  Rework changesets: Some callers may want to use `KeychainTxOutIndex` where `K` may change per descriptor on every run. So we only want to persist the last revealed indices by `DescriptorId` (which uniquely-ish identifies the descriptor).

  * rm `keychain_added` field from `keychain_txout`'s changeset.
  * Add `keychain_added` to `CombinedChangeSet` (which is renamed to `WalletChangeSet`).

  Rework persistence: add back some safety and convenience when persisting our types. Working with changeset directly (as we were doing before) can be cumbersome.

  * Intoduce `struct Persisted<T>` which wraps a type `T` which stores staged changes to it. This adds safety when creating and or loading `T` from db.
  * `struct Persisted<T>` methods, `create`, `load` and `persist`, are available if `trait PersistWith<Db>` is implemented for `T`. `Db` represents the database connection and `PersistWith` should be implemented per database-type.
  * For async, we have `trait PersistedAsyncWith<Db>`.
  * `Wallet` has impls of `PersistedWith<rusqlite::Connection>`, `PersistedWith<rusqlite::Transaction>` and `PersistedWith<bdk_file_store::Store>` by default.

  Rework wallet-construction: Before, we had multiple methods for loading and creating with different input-counts so it would be unwieldly to add more parameters in the future. This also makes it difficult to impl `PersistWith` (which has a single method for `load` that takes in `PersistWith::LoadParams` and a single method for `create` that takes in `PersistWith::CreateParams`).

  * Introduce a builder pattern when constructing a `Wallet`. For loading from persistence or `ChangeSet`, we have `LoadParams`. For creating a new wallet, we have `CreateParams`.

  ### Notes to the reviewers

  TODO

  ### Changelog notice

  ```
  ### Added

  - Add `sqlite` feature to `bdk_chain` which introduces methods on changeset types that encode/decode changesets to SQLite database.
  * Introduce `PersistWith<Db>` and `PersistAsyncWith<Db>` traits and a `Persisted` wrapper. This ergonomically makes sure user inits the db before reading/writing to it.

  ### Changed

  - Moved `bdk_chain::CombinedChangeSet` to `bdk_wallet::ChangeSet` and added `keychain_added` field.
  - `bdk_wallet::Wallet` construction now uses a builder API using the newly introduced `CreateParams` and `LoadParams`.

  ### Removed

  - Remove `keychains_added` field from `bdk_chain::keychain_txout::ChangeSet`.

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

  * [ ] I've added tests for the new feature
  * [x] I've added docs for the new feature

ACKs for top commit:
  LLFourn:
    ACK: 64eb5763487df3c6cbb626e51f96ab6e47c5de22
  notmandatory:
    Re ACK 64eb5763487df3c6cbb626e51f96ab6e47c5de22

Tree-SHA512: b8a1d48aea26d9fa293a8387a3533cd16c8ddae890f94d61fb91efa492fb05ac5e0a66200d64d7c857774368d5f0f8991a98684307029c25f50a1d8fceee8e67
2024-07-21 20:26:30 -05:00
2023-02-13 11:38:26 -06:00
2023-11-16 07:25:20 -06:00
2023-09-16 10:43:26 -05: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 Wallet 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:

  • wallet: 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
  • persist: Types that define data persistence of a BDK wallet
  • 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 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_wallet 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_wallet 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_wallet 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:

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"
cargo update -p cc --precise "1.0.105"

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%