Add two new traits:
- `StatelessBlockchain` is used to tag `Blockchain`s that don't have any
wallet-specic state, i.e. they can be used as-is to sync multiple wallets.
- `BlockchainFactory` is a trait for objects that can build multiple
blockchains for different descriptors. It's implemented automatically
for every `Arc<T>` where `T` is a `StatelessBlockchain`. This allows a
piece of code that deals with multiple sub-wallets to just get a
`&B: BlockchainFactory` to sync all of them.
These new traits have been implemented for Electrum, Esplora and RPC
(the first two being stateless and the latter having a dedicated
`RpcBlockchainFactory` struct). It hasn't been implemented on the CBF
blockchain, because I don't think it would work in its current form
(it throws away old block filters, so it's hard to go back and rescan).
This is the first step for #549, as BIP47 needs to sync many different
descriptors internally.
It's also very useful for #486.
e7a56a92685ce1948d2ec7232fccd7e072d4abb3 Change wallet::get_funded_wallet to return Wallet<AnyDatabase> (Steve Myers)
Pull request description:
### Description
Change testing function `wallet::get_funded_wallet` to return `Wallet<AnyDatabase>` instead of `Wallet<MemoryDatabase>`. This will allow us to use this function for testing `bdk-ffi` which only works with `Wallet<AnyDatabase>`.
### Notes to the reviewers
This is required to complete https://github.com/bitcoindevkit/bdk-ffi/pull/148.
### 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
* [ ] I've added docs for the new feature
* [ ] I've updated `CHANGELOG.md`
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [ ] I'm linking the issue being fixed by this PR
ACKs for top commit:
afilini:
ACK e7a56a92685ce1948d2ec7232fccd7e072d4abb3
Tree-SHA512: 47b53ab6dcee63fc7b24666d3cf9a0ad832782081dd2fe92961c8c9b4c302df90db96b0b518af71d6cbc85319434971219100f8cedb35ce7212d944db29a4295
4628a10191f451a7b0ade674e9f8568bf695e49c Fix typo in docs for TxBuilder allow_shrinking method (thunderbiscuit)
Pull request description:
### Description
This PR fixes a small typo in the documentation for the `allow_shrinking()` method on the `TxBuilder`.
### Notes to the reviewers
The sentence
```txt
Explicitly tells the wallet that it is allowed to reduce the fee of the output matching this `script_pubkey` in order to bump the transaction fee. Without specifying this the wallet will attempt to find a change output to shrink instead.
```
was changed for
```txt
Explicitly tells the wallet that it is allowed to reduce the amount of the output matching this `script_pubkey` in order to bump the transaction fee. Without specifying this the wallet will attempt to find a change output to shrink instead.
```
To reflect the fact that it's the _amount_ of the output that is being reduced in order to leave more for the fees.
### 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:
notmandatory:
ACK 4628a10191f451a7b0ade674e9f8568bf695e49c
Tree-SHA512: ca135764d78144295fdbdb4673ca6dec153c6f83ee7fb5d7d3051e0d46b04d23b2f3c3fd66e44491da842c778e72b52f8996d00e4c20986d7ccb11587f0d7d27
cca69481eb7edb28532a4ed78185248d410050ac Bump MSRV to 1.56 (Alekos Filini)
Pull request description:
### Description
Following the discussion in #331, bump the MSRV to `1.56`. We already have other PRs bumping it to at least `1.51` (#593), but I'm felling like we are always lagging behind and our CI breaks regularly. As @LLFourn suggested, this PR makes a relatively large bump, hoping this buys us enough time to finish splitting up BDK, which will allow us to have a lower MSRV for the "core" crate.
### 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:
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
notmandatory:
ACK cca69481eb7edb28532a4ed78185248d410050ac
Tree-SHA512: bc6572dc94e1c4cbb6d21f6e06a9730af5763fb4811311a61a6a6ec850b5a65664a21e4a7070a3ebcd702529fbba97b2e9a43c1277b9b9f092e194f16a39bc1a
6931d0bd1f044bf73c0cb760c0eb0be19aea8de1 add private function select_sorted_utxso to be resued by multiple CoinSelection impl (KaFai Choi)
545beec743412717895d0ba5d32ccd9aac68f4a6 add OldestFirstCoinSelection (KaFai Choi)
Pull request description:
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR is to add `OldestFirstCoinSelection`. See this issue for detail https://github.com/bitcoindevkit/bdk/issues/120
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
### Notes to the reviewers
Apologize in advance if the quality of this PR is too low.(I am newbie in both bitcoin wallet and rust).
While this PR seemed very straight-forward to me in the first glance, it's actually a bit more complicated than I thought as it involves calling DB get the blockheight before sorting it.
The current implementation should be pretty naive but I would like to get some opinion to see if I am heading to a right direction first before working on optimizations like
~~1. Avoiding calling DB for optional_utxos if if the amount from required_utxos are already enough.~~ Probably not worth to do such optimization to keep code simpler?
### 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:
* [x] I've added tests for the new feature
* [x] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [ ] I'm linking the issue being fixed by this PR
ACKs for top commit:
afilini:
ACK 6931d0bd1f044bf73c0cb760c0eb0be19aea8de1
Tree-SHA512: d297bbad847d99cfdd8c6b1450c3777c5d55bc51c7934f287975c4d114a21840d428a75a172bfb7eacbac95413535452b644cab971efb8c0b5caf0d06d6d8356
c752ccbddeaa5ae441cc74a1386c1e412a447104 Expose bip39::Error (志宇)
Pull request description:
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
Expose `bip39::Error` (fixes#581 )
### Notes to the reviewers
I am aware that the `bip39` module plans to be rewritten (as per #561 ), however this seems like a rather straightforward and quick change that may be useful in the short/mid term.
### Checklists
#### Bugfixes:
* [x] Expose `bip39::Error`
ACKs for top commit:
afilini:
ACK c752ccbddeaa5ae441cc74a1386c1e412a447104
Tree-SHA512: 98b7ac1ba88aed07d9160830ee80496c32d531c15ada0e9b50a97f0883fbfced22fa83a7c7f8366aadb7e7a667d8a63dde869d31cc375206d277e55b2ec3089d
b5c8ce924bc47d26a0d577bfcbdaf241c56aa253 Bump version to 0.19.0-dev (Steve Myers)
e3ce50059fca2d58587fdf4dd806ffacfef3d302 Bump version to 0.18.0 (Steve Myers)
8a2a6bbceeec3f682c789537ca619da821d34732 Add `n:` wrapper to vulnerable scripts (Alekos Filini)
122e6e71405f65ecb3c75adaff1e35ab5ef3a06e Bump 'miniscript' dependency version to '^6.1' (Steve Myers)
9ed36875f1112d884f6c3c2beab89faf8aa5d2e0 export: Rename `WalletExport` to `FullyNodedExport` (Alekos Filini)
f90e3f978e3c7ec5dde0a592d79da419a7c9ec3a Update changelog with addition of keychain to AddressInfo (Steve Myers)
68e1b32d81978746dba0abdd14af94edbfdcf9b4 Bump version to 0.18.0-rc.1 (Steve Myers)
Pull request description:
### Description
Release 0.18.0.
### Notes to the reviewers
This branch also includes the following changes which are not yet in the `master` branch:
- Rename `WalletExport` to `FullyNodedExport`, deprecate the former.
- Bump `miniscript` dependency version to `^6.1`.
### 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
* [ ] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
afilini:
ACK b5c8ce924bc47d26a0d577bfcbdaf241c56aa253
Tree-SHA512: d6a8c1ca2c13d3a84704592053cc450557c96229b0092e655ccf97775c3e0a23e9e1499cf8c9fc5a24fc0665ec0333d0ec6d6b06cb15eb2e14c033f06c3032c2
9ed36875f1112d884f6c3c2beab89faf8aa5d2e0 export: Rename `WalletExport` to `FullyNodedExport` (Alekos Filini)
Pull request description:
### Description
The `WalletExport` type can still be used as an alias to `FullyNodedExport` but it has been marked as deprecated and will be removed in the next release.
### 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
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
bucko13:
Concept ACK 9ed3687
notmandatory:
ACK 9ed36875f1112d884f6c3c2beab89faf8aa5d2e0
Tree-SHA512: fe07307092d3040b30ae96901d5fc4afecee635412bca4a0d2e78d90f07990e7bbcd6b87ed923bf5804385356f419cacadbfefbaf97ebc9a622e34548438ee00
The `WalletExport` type can still be used as an alias to
`FullyNodedExport` but it has been marked as deprecated and will be
removed in the next release.
44758f9483b049acbcd9f8948e29cd6f6add0cc2 Simplify the `rpcwallet` example using the improved keys traits (Alekos Filini)
c350064dae43fd9c892bb7dd272b14ce62f9e82d Update changelog changes in `keys` mod (Alekos Filini)
92746440db964b5e50f4017828516b36eb14e765 [keys] Make `GenerateKey<K>` clonable if K is (Alekos Filini)
e4eb95fb9cfbae3596deb310984fa18462d1b30c [keys] Implement `DerivableKey<Ctx>` for `(GeneratedKey<Mnemonic, Ctx>, Option<String>)` (Alekos Filini)
Pull request description:
### Description
I recently looked at the `rpcwallet` example and immediately thought the key generation part was very confusing. I made a few little changes to our traits and now I believe it's much better.
I'm copying the next few paragraphs from the first commit in this PR which explains why it's better not to extract the key from the `GeneratedKey` wrapper:
> This lets us use a tuple of (generated mnemonic, optional passphrase) as a `DerivableKey` directly, without extracting the inner mnemonic from the `GeneratedKey` wrapper. For BIP39 keys specifically it doesn't make much difference because the mnemonic format doesn't encode the network, but in general this is not the case and having a consistent API will make it harder for people to make mistakes.
> To explain why we should not extract the key: some key formats (like BIP32 extended keys) are network-specific, meaning that if somebody tries to use a Testnet key on a Mainnet BDK wallet, it won't work.
> However, when we generate a new key we would like to be able to use that key on any network, but we need to set some kind of placeholder for the `network` field in the structure. This is why (or at least one of the reasons why) we wrap the key in the `GeneratedKey` struct: we keep track of the "valid_networks" separately, which means that even if we set our BIP32 xprv to be a "Mainnet" key, once we go try creating a wallet with that key BDK is smart enough to understand that `GeneratedKey`s have their own separate set of valid networks and it will use that set to validate whether the key can be used in the wallet or not.
### Notes to the reviewers
I'm adding this to the `0.18` milestone even if the feature freeze is today. I don't think we should wait for this PR to start the release branch, but since it's just a minor addition to our traits I believe we could merge this afterwards to the release branch if we manage to get it reviewed and ready within the next week.
Otherwise it'll just wait for `0.19`, it's not a big deal.
### 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
* [ ] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
notmandatory:
tACK 44758f9483b049acbcd9f8948e29cd6f6add0cc2
Tree-SHA512: 31a8b5a3cd56c7c39688c4804026a8b6cee950c50ea880efcddc150ef523e2ddcc544831bf996a58b5cf3b7bc4a086c1008dc0728604e5134d331c68855c2d5b
This lets us use a tuple of (generated mnemonic, optional passphrase) as
a `DerivableKey` directly, without extracting the inner mnemonic from the
`GeneratedKey` wrapper. For BIP39 keys specifically it doesn't make much
difference because the mnemonic format doesn't encode the network, but in
general this is not the case and having a consistent API will make it
harder for people to make mistakes.
To explain why we should not extract the key: some key formats (like
BIP32 extended keys) are network-specific, meaning that if somebody
tries to use a Testnet key on a Mainnet BDK wallet, it won't work.
However, when we generate a new key we would like to be able to use that
key on any network, but we need to set some kind of placeholder for the
`network` field in the structure. This is why (or at least one of the
reasons why) we wrap the key in the `GeneratedKey` struct: we keep track
of the "valid_networks" separately, which means that even if we set our
BIP32 xprv to be a "Mainnet" key, once we go try creating a wallet with
that key BDK is smart enough to understand that `GeneratedKey`s have
their own separate set of valid networks and it will use that set to
validate whether the key can be used in the wallet or not.
a111d254769bfa698043cb9172a3e1cc84329ee4 Deprecate Database::flush() function (Steve Myers)
Pull request description:
### Description
The Database::flush() function is only needed for the sled database on mobile, instead for mobile use the sqlite database.
### Notes to the reviewers
This PR is in preparation for removing the Database::flush() function. See https://github.com/bitcoindevkit/bdk/pull/575#issuecomment-1082916667.
After the `release/0.18.0` feature freeze branch is created then #575 should be merged.
### 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
* [ ] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
afilini:
ACK a111d254769bfa698043cb9172a3e1cc84329ee4
Tree-SHA512: 18434dc95dbef47118a0d4fface908bdf920a7ffcef927b36bb740c15f8efcf11dea9198b364648f16f74aaec4aa18e92a3c5e925299b2f3b9d69e566f89e790
adef166b22d5c95006df39fd8c57574624071189 Create vector of thread handles to spawn threads (nickfarrow)
Pull request description:
### Description
Speeds up esplora ureq syncing. Taken from https://github.com/bitcoindevkit/bdk/pull/560
The current sync just creates a map of scripts to joinhandles which doesn't yet spawn the sync threads due to lazy evaluation. In the following `handles.map()`, the thread handles are *sequentially* evaluated and joined. With the fix, the handles are collected so that the threads spawn in parallel, and then joined
### Notes to the reviewers
I had to add a `#[allow(clippy::needless_collect)]` so that it wouldn't complain about collecting and then iterating. (Perhaps clippy is partially responsible for this issue!)
Tested sync performance by doing a fresh sync on an existing [gun](https://gun.fun) wallet.
```
---- Before fix ---
real0m13.121s
real0m13.367s
real0m13.211s
---- After fix ----
real0m5.516s
real0m5.251s
real0m5.594s
```
### 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
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [ ] I'm linking the issue being fixed by this PR
ACKs for top commit:
notmandatory:
ACK adef166b22d5c95006df39fd8c57574624071189
Tree-SHA512: 47c617117afde9b4706bfa63759bf06d1ec60ff95d8a80931e5b7e40e3293c855d2f7dac0c681173d43aecf77201a842e739b82291da09ac81909cf526a51c8d
1b9014846c5cb690f5c37f70556717b788a0733b Update changelog (Alekos Filini)
86abd8698f34d91f94bfce896affb535cca27146 [descriptor] Expose utilities to deal with derived descriptors (Alekos Filini)
0d9c2f76e00af801668fa2a70fcd13f9e399c0d2 [export] Use the new getters on `Wallet` to generate export JSONs (Alekos Filini)
63d5bcee934febe4d38622b677131bbe2e1a0abe [wallet] Add more getters (Alekos Filini)
Pull request description:
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
Expose more getters and internal utilities for people who need to work with descriptors.
A good example of how this can be leveraged is in the second commit, which refactors the wallet export functionality to use the new public APIs rather than using members on `Wallet` directly.
### 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
* [x] I've updated `CHANGELOG.md`
ACKs for top commit:
notmandatory:
ACK 8cd055090d75669c67a44467cc0281465ef31270
Tree-SHA512: 3e8833670ebc56316fce01fc572fcc9391d602ef85f0cde8edcb446295570a9012e18f6ba8af0984153e4688f66f7eea6803ef610ceb395867e464e05c01c137
2698fc0219eb360e84a89ceabba4793777bf550b update AddressInfo struct (eunoia_1729)
Pull request description:
### Description
Resolves#541.
- Updates `AddressInfo` struct to include `keychainKind`
- Updates the related `get_address` functions to pass in this field
- Updates corresponding tests
### 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
Top commit has no ACKs.
Tree-SHA512: b1d22e5f322e1a35390fb06a5185457bd53af7c4a9c4e6e2fd5e93b967fa3f56af5848ac314e63e2b0becd60dbc8a4eeb761a2bdebfe8ba43ce49b13da4190b2
364ad95e85bd09a01cb4cbf3ceb9e9fcc074c8b4 Fix hierarchy of headers on docs landing page (thunderbiscuit)
Pull request description:
### Description
This PR fixes the hierarchy of headers on the lib.rs docs. I noticed it as I was reading through the docs. The new hierarchy is the following:
- About (h1)
- A tour of BDK (h1)
- Examples (h1)
- Sync the balance of a descriptor (h2)
- Generate a few addresses (h2)
- Create a transaction (h2)
- Sign a transaction (h2)
- Feature flags (h1)
- Internal features (h1)
### 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:
rajarshimaitra:
tACK 364ad95e85
Tree-SHA512: b4439a200c320a1815c572ac36b81c4d684209cb5cf1b90d3f761893ad672a270722be7d7b61d77434a7f98c4276d6fc9694d0c86cacf03c72dc35ca17b5e7d3
8a98e69e788dd79d030798465fbc0dec044d86f1 Add rpc wallet creation example (rajarshimaitra)
Pull request description:
### Description
As mentioned in https://github.com/bitcoindevkit/bitcoindevkit.org/issues/83#issuecomment-1005190174 it would be helpful
to have wallet creation example code in the `example` directory.
This is an attempt to create the most simplistic bdk wallet with a RPC backend and demonstrate receiving, creating, signing
and broadcasting transaction.
The code is a refinement of the RPC tutorial https://bitcoindevkit.org/blog/bitcoin-core-rpc-demo/ with more elaborate doc comments.
### Notes to the reviewers
To automate the background RPC process `electrsd` is used which is already a `dev-dependency` of bdk.
### 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:
notmandatory:
tACK 8a98e69e788dd79d030798465fbc0dec044d86f1
Tree-SHA512: f00c1ce57ef91c3d3ab2ce08af3571c41bbe98f18f705c61ba4217c2f8061196e5eaf6122742293cd6fa16939bbbfacd0f8506cd4151b55f19a05325fd94a74a
1803f5ea8a7a2f8f9ebdfa520baad91f84bd6ba0 Update `electrsd` to v0.15 (Alekos Filini)
Pull request description:
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
PR RCasatta/electrsd#33 has been merged and the new changes released as part of `v0.15.0`: the PR allows setting an env variable (`ELECTRSD_EXE`) to use a custom electrsd binary, which can be useful when the one that is downloaded automatically doesn't work for whatever reason.
### 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
* [ ] I've added docs for the new feature
* [ ] I've updated `CHANGELOG.md`
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [ ] I'm linking the issue being fixed by this PR
ACKs for top commit:
LLFourn:
ACK 1803f5e
notmandatory:
ACK 1803f5ea8a7a2f8f9ebdfa520baad91f84bd6ba0
Tree-SHA512: 01d84763a5acf3aa1686b91ba7cb0c7ec3a0ca6c7b9bac29aa74a72f54ed31c476b7a8b0f8c6c8a8ccf530ad8a19e90e144ac4cacbe436699ef9e319b5732f1c
