2023-12-06 21:21:02 -06:00
|
|
|
//! This crate is a collection of core structures for [Bitcoin Dev Kit].
|
2023-03-01 11:09:08 +01:00
|
|
|
//!
|
2023-03-10 23:23:29 +05:30
|
|
|
//! The goal of this crate is to give wallets the mechanisms needed to:
|
2023-03-01 11:09:08 +01:00
|
|
|
//!
|
|
|
|
//! 1. Figure out what data they need to fetch.
|
2023-03-10 23:23:29 +05:30
|
|
|
//! 2. Process the data in a way that never leads to inconsistent states.
|
|
|
|
//! 3. Fully index that data and expose it to be consumed without friction.
|
2023-03-01 11:09:08 +01:00
|
|
|
//!
|
|
|
|
//! Our design goals for these mechanisms are:
|
|
|
|
//!
|
|
|
|
//! 1. Data source agnostic -- nothing in `bdk_chain` cares about where you get data from or whether
|
2023-03-10 23:23:29 +05:30
|
|
|
//! you do it synchronously or asynchronously. If you know a fact about the blockchain, you can just
|
|
|
|
//! tell `bdk_chain`'s APIs about it, and that information will be integrated, if it can be done
|
2023-03-01 11:09:08 +01:00
|
|
|
//! consistently.
|
2023-10-17 11:00:05 +02:00
|
|
|
//! 2. Data persistence agnostic -- `bdk_chain` does not care where you cache on-chain data, what you
|
|
|
|
//! cache or how you retrieve it from persistent storage.
|
2023-03-01 11:09:08 +01:00
|
|
|
//!
|
|
|
|
//! [Bitcoin Dev Kit]: https://bitcoindevkit.org/
|
2023-05-29 21:54:53 +08:00
|
|
|
|
2023-03-01 11:09:08 +01:00
|
|
|
#![no_std]
|
2023-05-29 21:54:53 +08:00
|
|
|
#![warn(missing_docs)]
|
|
|
|
|
2023-03-01 11:09:08 +01:00
|
|
|
pub use bitcoin;
|
2024-06-28 09:07:36 -04:00
|
|
|
mod balance;
|
|
|
|
pub use balance::*;
|
2023-03-01 11:09:08 +01:00
|
|
|
mod chain_data;
|
|
|
|
pub use chain_data::*;
|
2023-03-27 14:21:10 +08:00
|
|
|
pub mod indexed_tx_graph;
|
2023-05-29 21:54:53 +08:00
|
|
|
pub use indexed_tx_graph::IndexedTxGraph;
|
2024-06-28 09:07:36 -04:00
|
|
|
pub mod indexer;
|
feat!: Rework sqlite, changesets, persistence and wallet-construction
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
avaliable 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`.
2024-07-11 04:49:01 +00:00
|
|
|
pub use indexer::spk_txout;
|
2024-06-28 09:07:36 -04:00
|
|
|
pub use indexer::Indexer;
|
2023-03-29 22:45:01 +08:00
|
|
|
pub mod local_chain;
|
2023-03-01 11:09:08 +01:00
|
|
|
mod tx_data_traits;
|
|
|
|
pub mod tx_graph;
|
|
|
|
pub use tx_data_traits::*;
|
2023-05-29 21:54:53 +08:00
|
|
|
pub use tx_graph::TxGraph;
|
2023-04-05 10:57:26 +08:00
|
|
|
mod chain_oracle;
|
|
|
|
pub use chain_oracle::*;
|
feat!: Rework sqlite, changesets, persistence and wallet-construction
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
avaliable 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`.
2024-07-11 04:49:01 +00:00
|
|
|
mod persist;
|
|
|
|
pub use persist::*;
|
2023-03-01 11:09:08 +01:00
|
|
|
|
|
|
|
#[doc(hidden)]
|
|
|
|
pub mod example_utils;
|
|
|
|
|
|
|
|
#[cfg(feature = "miniscript")]
|
|
|
|
pub use miniscript;
|
|
|
|
#[cfg(feature = "miniscript")]
|
|
|
|
mod descriptor_ext;
|
|
|
|
#[cfg(feature = "miniscript")]
|
2024-01-15 18:52:03 +01:00
|
|
|
pub use descriptor_ext::{DescriptorExt, DescriptorId};
|
2023-03-22 17:00:08 +08:00
|
|
|
#[cfg(feature = "miniscript")]
|
|
|
|
mod spk_iter;
|
|
|
|
#[cfg(feature = "miniscript")]
|
feat!: Rework sqlite, changesets, persistence and wallet-construction
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
avaliable 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`.
2024-07-11 04:49:01 +00:00
|
|
|
pub use indexer::keychain_txout;
|
2024-07-17 14:37:10 +00:00
|
|
|
#[cfg(feature = "miniscript")]
|
|
|
|
pub use spk_iter::*;
|
feat!: Rework sqlite, changesets, persistence and wallet-construction
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
avaliable 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`.
2024-07-11 04:49:01 +00:00
|
|
|
#[cfg(feature = "sqlite")]
|
|
|
|
pub mod sqlite;
|
|
|
|
#[cfg(feature = "sqlite")]
|
|
|
|
pub use rusqlite;
|
2024-04-24 16:05:59 +08:00
|
|
|
pub mod spk_client;
|
2023-03-01 11:09:08 +01:00
|
|
|
|
|
|
|
#[allow(unused_imports)]
|
|
|
|
#[macro_use]
|
|
|
|
extern crate alloc;
|
|
|
|
|
|
|
|
#[cfg(feature = "serde")]
|
|
|
|
pub extern crate serde_crate as serde;
|
|
|
|
|
|
|
|
#[cfg(feature = "std")]
|
|
|
|
#[macro_use]
|
|
|
|
extern crate std;
|
|
|
|
|
|
|
|
#[cfg(all(not(feature = "std"), feature = "hashbrown"))]
|
|
|
|
extern crate hashbrown;
|
|
|
|
|
|
|
|
// When no-std use `alloc`'s Hash collections. This is activated by default
|
|
|
|
#[cfg(all(not(feature = "std"), not(feature = "hashbrown")))]
|
|
|
|
#[doc(hidden)]
|
|
|
|
pub mod collections {
|
|
|
|
#![allow(dead_code)]
|
|
|
|
pub type HashSet<K> = alloc::collections::BTreeSet<K>;
|
|
|
|
pub type HashMap<K, V> = alloc::collections::BTreeMap<K, V>;
|
|
|
|
pub use alloc::collections::{btree_map as hash_map, *};
|
|
|
|
}
|
|
|
|
|
2023-03-10 23:23:29 +05:30
|
|
|
// When we have std, use `std`'s all collections
|
2023-03-01 11:09:08 +01:00
|
|
|
#[cfg(all(feature = "std", not(feature = "hashbrown")))]
|
|
|
|
#[doc(hidden)]
|
|
|
|
pub mod collections {
|
|
|
|
pub use std::collections::{hash_map, *};
|
|
|
|
}
|
|
|
|
|
2023-03-10 23:23:29 +05:30
|
|
|
// With this special feature `hashbrown`, use `hashbrown`'s hash collections, and else from `alloc`.
|
2023-03-01 11:09:08 +01:00
|
|
|
#[cfg(feature = "hashbrown")]
|
|
|
|
#[doc(hidden)]
|
|
|
|
pub mod collections {
|
|
|
|
#![allow(dead_code)]
|
|
|
|
pub type HashSet<K> = hashbrown::HashSet<K>;
|
|
|
|
pub type HashMap<K, V> = hashbrown::HashMap<K, V>;
|
|
|
|
pub use alloc::collections::*;
|
|
|
|
pub use hashbrown::hash_map;
|
|
|
|
}
|
|
|
|
|
2023-03-10 23:23:29 +05:30
|
|
|
/// How many confirmations are needed f or a coinbase output to be spent.
|
2023-03-01 11:09:08 +01:00
|
|
|
pub const COINBASE_MATURITY: u32 = 100;
|
2024-06-28 09:07:36 -04:00
|
|
|
|
|
|
|
/// A tuple of keychain index and `T` representing the indexed value.
|
|
|
|
pub type Indexed<T> = (u32, T);
|
|
|
|
/// A tuple of keychain `K`, derivation index (`u32`) and a `T` associated with them.
|
|
|
|
pub type KeychainIndexed<K, T> = ((K, u32), T);
|