7 releases
new 0.11.0-beta.9 | Oct 31, 2024 |
---|---|
0.11.0-beta.8 | Sep 5, 2024 |
0.11.0-beta.7 | Aug 18, 2024 |
0.11.0-beta.6 | Jun 8, 2024 |
0.11.0-beta.3 | Dec 25, 2023 |
#125 in Magic Beans
1,071 downloads per month
Used in 6 crates
(via bp-std)
145KB
3K
SLoC
Bitcoin standards implementation libraries
Modern, minimalistic & standard-compliant wallet-level libraries: an alternative
to rust-bitcoin
and BDK libraries from LNP/BP Standards Association.
The main goals of the libraries are:
- fast stabilization of APIs: the library will be targeting v1.0 version
within the first year of its development; which should enable downstream
crates using the library also to stabilize and not spend too much effort
on changing the integration each time the new version of
bp-wallet
is released; - no use of private keys: the library analyzes wallet state using descriptors and allows to produce unsigned PSBTs, as well as publish and analyze (partially) signed PSBTs - but doesn't provide a signer or a way to work with any private key material (seeds, mnemonics, xprivs, private keys); PSBT files must be signed with some external signers or hardware wallets;
- standard-compliance: the library tries to provide full compliance with existing bitcoin standards defined in BIPs and do not use any legacy approaches or "blockchain-not-bitcoin" practices (like the ones provided by BLIPs);
- separation of bitcoin consensus and standards: the consensus-related
code is not a part of this library; all data structures and business logic
which may have consensus meaning and is required for a wallet is separated
into an independent
bp-primitives
library (a part ofbp-core
library), which is planned to be more extensively audited and ossified alongside bitcoin protocol (while this library will continue to evolve with better APIs and to match new wallet standards); - extensive use of descriptors: library focuses on defining all parts of a wallet using descriptors; additionally to script pubkey descriptors it also supports xpub descriptors, derivation descriptors, applied to script pubkey descriptor as a whole, and input descriptors for RBFs. You can read more on specific descriptor types in the section below;
- script templates: the library allows to provide an arbitrary script as a part of a descriptor, which allows support for BOLT lightning channel transaction and makes it possible to ensure stability in the long run; you can read more about script templates vs miniscript below;
- opinionated high-level wallet abstractions: the library provide a set of high-level wallet data structures abstracting away blockchain-level details; helping in writing less boilerplate business logic;
- APIs usable in all rust projects and in FFI: the library doesn't use
async rust, complex callbacks, threads etc., which allows to keep the API
simple, usable from any rust app (like ones using reactive patterns instead of
async); at the same time all the data structures of the library are
Send + Sync
, meaning that they can be used in any multi-thread or async environment; - abstracted blockchain data providers: the library abstracts blockchain indexer APIs (Electrum, Esplora, Bitcoin Core etc.) and also provides their implementation using this library structures.
FAQs
Why not use rust-bitcoin
?
The library doesn't rely on rust-bitcoin
crate. The reasons for that are:
- to keep the functionality set small and wallet-specific:
rust-bitcoin
provides "all in one" solution, covering many parts of bitcoin ecosystem, like bitcoin peer-to-peer protocol, not really used by a wallet; - to keep API stable:
rust-bitcoin
with each release significantly breaks APIs, being in constant refactoring since early 2022 - a process likely to last for few years more; update of wallet libraries after each major change is painful and takes a lot of developers time and effort, as well as introduces API breaking changes downstream preventing all dependent libraries from stabilization; - separation of private key material: in Rust it is impossible to achieve
constant-time production of secret key material, as well as prevent the
compiler from copying it all over the machine memory (
zeroise
and other approaches doesn't prevent that). Thus, providing secret keys alongside other APIs may lead to non-secure design of the wallet and should be avoided; - separation of consensus code from standards:
rust-bitcoin
provides next to each other consensus-related structures and higher level wallet abstractions, which contradicts to the design decision we are making in this library; - to introduce strong semantic typing: for instance,
rust-bitcoin
doesn't differentiate different forms of scripts (pubkey, sig, witness etc.), while in this library we are using semantic type approach, providing type-safe variants for each semantically-distinct entity even if it shares the same representation with others.
As one may see from the list, rust-bitcoin
design and maintenance approach
contradicts to the major aims of this project - in fact, this project was
created by Maxim Orlovsky (who was the most active contributor to
rust-bitcoin
since Q1 2019 till Q2 2022) in order to address these issues
using different set of trade-offs, providing an alternative to rust-bitcoin
to those who needs it.
Why not use miniscript?
Miniscript is great for many purposes, but it can't be used for many cases,
including representation of BOLT-3 lightning channel transaction outputs,
re-use of public key in different branches of pre-taproot scripts [1][ms-1].
Miniscript is also still unstable, having recent changes to the semantic due
to discovered bugs [2][ms-2] [3][ms-3]; meaning that the descriptors created
with miniscript before may not be able to deterministically reproduce the
structure of some wallet UTXOs in a future. Finally, the existing Rust
miniscript implementation rust-miniscript
inherits all rust-bitcoin
tradeoffs, and is much more unstable in terms of APIs and semantic. Thus, it was
decided to use this library to provide an alternative to miniscript with
introduction of [script templates][#script-templates] convertible to and from
miniscript representation - but with some externally-provided tools instead
of adding miniscript as a direct dependency here.
Why not BDK?
BDK is great, but it relies on rust-bitcoin
and rust-miniscript
and can't
be used outside of that ecosystem, inheriting all tradeoffs described above.
Since we try to address those trade-offs, we had to create a BDK alternative.
How this project is related to descriptor-wallet
?
Descriptor wallet was an earlier project by the same
authors trying to address rust-bitcoin
issues by building on top of it. With
the recent v0.30 rust-bitcoin
release it became clear that the effort of
adoption to API-breaking changes is much higher than creating a new independent
project from scratch, while at the same time the new project may address
rust-bitcoin
issues in much more efficient and elegant way. Thus, it was
decided to discontinue descriptor-wallet
and start the new bp-wallet
project
instead.
Design
Script templates
Descriptors
Contributing
Contribution guidelines can be found in CONTRIBUTING
More information
MSRV
Minimum supported rust compiler version (MSRV) is shown in rust-version
of Cargo.toml
.
Policy on altcoins
Altcoins and "blockchains" other than Bitcoin blockchain/Bitcoin protocols are not supported and not planned to be supported; pull requests targeting them will be declined.
Licensing
The libraries are distributed on the terms of Apache 2.0 opensource license. See LICENCE file for the license details.
Dependencies
~13MB
~190K SLoC