BDK Roadmap Planning

[notmandatory]

Post high level improvements (fixes, features, refactoring) you'd like to see in a future bdk_wallet or bdk_chain repo release. If you also have a milestone in mind add that (ie. 2.0, 3.0, ...) or a year (2025, 2026, ...). Also add links to any supporting open issues or PRs. Make one post per feature with high level summary, comments go in below reply thread.

[notmandatory]

bdk_wallet: Multi-descriptor Wallets

Currently BDK wallets only support two descriptors, external and optional internal. Supporting multiple descriptors would make it possible to monitor and spend from descriptors with different script types for the same key which the bitcoind wallet does to improve privacy. It would also make it easier to safely roll over from one script type to a new one by changing which descriptors are used for change and new receive addresses, while still monitoring old descriptors for new UTXOs.

This is a large-ish new feature, so I propose we do it for a 4.0 or some time in 2026.

See:
bitcoindevkit/bdk_wallet#28
bitcoindevkit/bdk_wallet#189
bitcoindevkit/bdk_wallet#188

[notmandatory]

This could be done sooner as a non-breaking change if we don't try to change the existing Wallet type and start by creating an "experimental" MultiWallet type instead.

[notmandatory]

bdk_wallet: Replace TxBuilder with bdk-tx crate

The bdk-tx crate is a transaction building library based on rust-miniscript that lets you build, update, and finalize PSBTs. The bdk-tx crate uses the rust-miniscript planning module instead of the bdk_wallet policy module and makes it easier to construct a tx when multiple spending paths are possible. Extracting transaction creation to it's own project will also allow other projects that don't need the full bdk_wallet functionality to use it.

I suggest we focus on only extracting the existing TxBuilder functionality and fixing any bugs we can. New builder features should be added in later releases.

This is a large new feature, but work has already begun on bdk-tx so I propose we target the 3.0 milestone for this feature.

See:
https://github.com/bitcoindevkit/bdk-tx
bitcoindevkit/bdk_wallet#151
bitcoindevkit/bdk_wallet#164
bitcoindevkit/bdk_wallet#15

[notmandatory]

bdk_wallet: Support Multipath Descriptors

This is a frequently requested feature that shouldn't require any big changes to the Wallet constructing functions. The main blocker is deciding what API would make the most sense.

This is a small feature that would be great to see in a 2.0, 3.0 or 3.1 milestone.

See:
bitcoindevkit/bdk_wallet#11

[reez]

+1 for this

[thunderbiscuit]

Here is my 3.0 wishlist!

1. Revamp transaction building by leveraging bdk-tx. Either by replacing the internals of the current TxBuilder to leverage bdk-tx logic or simply by removing the TxBuilder entirely and adding new methods on the Wallet directly.
2. Remove transaction signing from wallet. Sidequest to this: better return value on psbt signing. additional information for sign when returning false  bdk_wallet#73 and Feature Request: Return a structured error type instead of a bool on failed finalization bdk#1939.
3. Support for multiple keychains.
4. Cleanup of the wallet constructors. Error out when certain things are wrong, potentially better names for them, cleaner separation of loaders/checkers. Support for multipath descriptors.

[reez]

+1 for main quest and side questRemove transaction signing from wallet. Sidequest to this: better return value on psbt signing

[notmandatory]

For "cleanup wallet constructors" how would you feel about a single constructor that takes a multi or non-multi path descriptor?

[thunderbiscuit]

I'm not married to the idea of multiple constructors if we can fit it all cleanly into one, but I do I have some thoughts on the types of things I'm looking to get certainty on and I think the constructors might be a good place for it in the sense that different constructors return different types (number of keychains) wallets (but there might be other ways to do it!) as stated here.

My main thought is that at the moment I sort of rely on the constructor to get clarity on the type of wallet that will come out of it (i.e. the number of keychains this wallet will have). This is important because (and here I quote the docs):

For a wallet with no internal (change) keychain, any methods requiring a KeychainKind as input, e.g. Wallet::reveal_next_address should only be called with the External variant. In some cases passing Internal is treated the same as External but this behavior must not be relied on.

I'm wondering where that certainty (around the number of keychains and hence reliance on certain APIs) should come from if not from the constructor. Note that in many cases the descriptors will be user-provided strings and the software will pass them on to the constructors. If you only have one constructor and don't know the type of wallet that comes out of it because it can be many things, you might have unexpected things happen:

• Ex 1: you treat the wallet as single-descriptor, but the user provided a multi-descriptor with a change keychain so now some scripts are created on the change keychain
• Ex 2: the user provides a multipath descriptor of 5 indices, but you only read the first 2. They can't see their balance they find on other software for this same multpath descriptor

I initially thought of those as constructors that offer certainties about what types of wallets (i.e. single vs double keychains wallets) will come out of them (Wallet::create needs 2 descriptors and if you don't it errors out, Wallet::create_single takes only one descriptor and errors out if you give it more, and Wallet::create_multi takes one descriptors but must expand into 2 or more). Was this maybe the wrong mental model for it? Should this logic/checks live somewhere else maybe and I was sort of relying on the API in the wrong way? There might be other places for these sorts of checks/logic to exist.

[thunderbiscuit]

My post above could get unruly if we unpack all items in one go so not sure how to best do this but I'll create a new post for item number 3: Support for multiple keychains.

A rough outline of what I think would be a good API is a wallet that takes any number of keychains (maybe wrapped together in a data structure called a keyring or something?). The keychain enum is roughly this:

pub enum Keychain {
    Default,
    Change,
    Other(name), // Standard?
}

The wallet takes a KeyRing (or KeychainSet), and this KeyRing type has the following properties:

• Must have at least one Keychain
• Must have one (and only one) Keychain::Default
• Can have at most one Keychain::Change
• Can have any number of Keychain::Standard or Keychain::Other. The user can refer to these by name or some other identifier when revealing addresses or building transactions and whatnot.

[luisschwab]

I like the idea of a KeyRing, pretty neat.