This test simulates a situation where the last write to the db is short.
Aggregating the changeset after reopening the file should return an
error (which includes a partially-aggregated changeset) containing an
aggregation of changesets that were fully written.
At this point, the test re-writes the final changeset (and this time it
successfully writes in full).
The file should be recoverable with all changesets, including the last
one.
* Wrap file reader with `BufReader`. This reduces calls to `read`.
* Wrap file reader with `CountingReader`. This counts the bytes read by
the underlying reader. We can rewind without seeking first.
5b7794299308cd81a2ebbe0aa2b1be1d4c47680b fix(example_electrum): init LocalChain from genesis (vmammal)
Pull request description:
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
This should fix#1252
### 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:
evanlinjin:
ACK 5b7794299308cd81a2ebbe0aa2b1be1d4c47680b
Tree-SHA512: bf049edb2ba22abb949dfd4cb38608589287f3f374f397c82f778b59c21010daa80b63ad85c442c4ee00a2608f89a8d50447b0db85d15caac7fd0b4fd8956e1a
761189ab2b679fbfee45b33435d66ed98a135e2a feat(chain): debug_assert non-wildcard desc. to only cache index 0 (志宇)
887e112e8f4ee5300bf09a0f3590861bff7fd053 ref(chain): Refactor reveal_to_target (Daniela Brozzoni)
21d88758262bfbc3d9d2109aac9883f23ab651c4 ref(chain): Refactor next_store_index (Daniela Brozzoni)
Pull request description:
### Description
As a part of #1203, I found myself having to modify `reveal_to_target`, but had some troubles understanding exactly what the method was doing.
This PR refactors `reveal_to_target` to be, in my opinion, a bit clearer. We now exist prematurely if `next_reveal_index` < `target_index`; this way, we don't need to keep track of `next_reveal_index`, as it would always be equal to `Some(target_index)`.
As a part of trying to understand `reveal_to_target` I had to read through `next_store_index`, I slightly improved it for clarity reasons as well.
### Changelog notice
### 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:
evanlinjin:
ACK 761189ab2b679fbfee45b33435d66ed98a135e2a
Tree-SHA512: 17f70bccbfa1cccf718ece0eeb61f4944c9108776cf1d606ef823ae9ff58bf52114750927ac99561644ece598f8131ee7f7605071d42c91e5e88e05035e74836
8f6dad76efaa4af0ebb990ed83632f230fd10d94 Bump bdk_esplora and bdk_file_store versions for 1.0.0-alpha.3 release (Steve Myers)
Pull request description:
### Description
These crates need to have their versions bumped because the version of bdk_chain was bumped to 0.7.0 with the 1.0.0-alpha.3 release.
bdk_esplora to 0.5.0
bdk_file_store to 0.3.0
After this PR is merged I'll publish new versions of these crates to crates.io.
### Notes to the reviewers
I should have done this as part of the 1.0.0-alpha.3 release process. This problem was found when @thunderbiscuit started updating the bdk-ffi project to alpha.3 and we got type mismatch errors for bdk_chain types used in bdk_esplora.
ACKs for top commit:
thunderbiscuit:
ACK 8f6dad76efaa4af0ebb990ed83632f230fd10d94.
Tree-SHA512: 735094a5d78da082437118a38db085b12c26665c8cf8fd809d62dbe9a058ee04c59a165e454b3eb8baea4209330083a6a7bce8c303be1660f6593c80ccbe46b7
These crates need to have their versions bumped because the version of bdk_chain was bumped to 0.7.0 with the 1.0.0-alpha.3 release.
bdk_esplora to 0.5.0
bdk_file_store to 0.3.0
Simplify the `reveal_to_target` algorithm by exiting prematurely if
the `target_index` is already revealed.
Since the `reveal_to_index` variable was different from
`Some(target_index)` only if the target was already revealed, we can
getrid of the variable altogether.
105d70e9743f651d141c6e0d901d60d583afd4d9 ref(hwi): Move hwi out of bdk (Daniela Brozzoni)
Pull request description:
Fixes#872
### Description
This commit moves the `hardwaresigner` outside of bdk and inside `bdk_hwi`
### Notes to the reviewers
There are currently two issues with the code:
- `TransactionSigner` dictates that `sign_transaction` must return a `SignerError` - but being `SignerError` defined inside of bdk, we can't modify it to include an hwi specific error! I don't know how we could fix this (other than getting rid of the trait altogether :)); for now I just added a `SignerError::Generic` variant, lmk if you have better ideas!
- The hwi tests used the bdk utils to get a funded wallet for testing, which aren't available in `bdk_hwi`, which made me realize - maybe we should expose them so that we can use them across our crates, and also our users can use them to test their code?
For now, I just left the test commented.
### Changelog notice
- The old `hardwaresigner` module has been moved out of `bdk` and inside `bdk_hwi`.
### 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:
notmandatory:
reACK 105d70e9743f651d141c6e0d901d60d583afd4d9
Tree-SHA512: 9ae3cd035cc27bd7b2831e89c104f40771c6f165cb3bfe1a9052f820050fca7c19f4dd68f171c630a71a7d18ccdee5f94adbc497c6475bd257c2d01cc08109a1
003271117cb347556cc82455558da40ef50a1156 Bump bdk version to 1.0.0-alpha.3 (Steve Myers)
Pull request description:
### Description
- Bump bdk version to 1.0.0-alpha.3
- Bump bdk_chain to 0.7.0
- Bump bdk_bitcoin_rpc to 0.2.0
- Bump bdk_electrum to 0.5.0
### Notes to the reviewers
### Changelog notice
See #1254
### 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:
evanlinjin:
ACK 003271117cb347556cc82455558da40ef50a1156
Tree-SHA512: ac0756f52436880fe633e9ecb83f3d53f485ccfa89a3a89aa51ee4ba5da5cee87f507da69a9e1271f8aaf4425f65d04fb201ea9a4f64bce18f96039ea3548d61
8694624bd5f63b738448c250d7b1042f219636da Bump `bip39` to v2.0 (Elias Rohrer)
Pull request description:
We previously bumped the `bip39` version to 2.0 [in the 0.2X release branch](https://github.com/bitcoindevkit/bdk/pull/875). Back then, bumping it in `master` was [assumed unnecessary](https://github.com/bitcoindevkit/bdk/pull/875#issuecomment-1483990088). It seems this was erroneous, as the current `1.0.1` dependency is present since https://github.com/bitcoindevkit/bdk/pull/793, which was merged before the bump in `release/0.27`.
Here, we therefore bump the crate version in `master` after all.
ACKs for top commit:
notmandatory:
ACK 8694624bd5f63b738448c250d7b1042f219636da
Tree-SHA512: a109219bc97bb8e965e8b10e72439aa898b710d1d1a154801ce499ad47475a6b23448d85e0de3f306f990573d1fccdae7d587ed41676a01f91d66a719782eae1
We previously bumped the `bip39` version to 2.0 in the 0.2X release
branch. Back then, bumping it in `master` was erroneously considered unnecessary.
Here, we therefore bump the crate version in `master` after all.
028caa9f8cd51afba0fdc81748fc8cf536c75cd0 fix(typos): existant -> existent (Jose Storopoli)
Pull request description:
### Description
These typos are blocking the Nix typo CI in #1257
### Notes to the reviewers
Blocking #1257
### Changelog notice
- fix: typos in documentation
-
### 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
#### 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 028caa9f8cd51afba0fdc81748fc8cf536c75cd0
Tree-SHA512: 0bd91efd0eec55fdc537824435552c968858a5b827179b3f9f3f37785db3fa92d3e6f0c73023de0c506224c81217c402d5afa8a2f768fecaf6a3c8378226d184
a1d34afa2455d93d23a36fd78d94aa79c7e493d1 feat(wallet)!: add `NonEmptyDatabase` variant to `NewError` (志宇)
Pull request description:
### Description
`NewError` is the error type when constructing a wallet with `Wallet::new`. We want this to return an error when the database already contains data (in which case, the caller should use `load` or `new_or_load`).
### Notes to the reviewers
This is cherry-picked from #1172 so that we can add it to the alpha.3 release.
### Changelog notice
Change
- Return `NonEmptyDatabase` error when constructing a wallet with `Wallet::new` if the file already contains data (in which case, the caller should use `load` or `new_or_load`).
### 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
ACKs for top commit:
evanlinjin:
ACK a1d34afa2455d93d23a36fd78d94aa79c7e493d1
Tree-SHA512: 7c20171fa3d7dee5b1ac24f8a808781dbb0be0034951005e1e87acdf023123c01161e225b47b6d4484865889778c39549a3780f641227ddc0f84d1577d69f40a
`NewError` is the error type when constructing a wallet with
`Wallet::new`. We want this to return an error when the database already
contains data (in which case, the caller should use `load` or
`new_or_load`).
de54e710ed04e3cb1632cf99dbc1c6f2374b0c6e refactor(esplora_ext): rename scan_txs to sync and scan_txs_with_keychains to full_scan (Steve Myers)
95d34854f46fd154eed35008954b25b82785b2d8 refactor(electrum_ext): rename scan_without_keychain to sync and scan to full_scan (Steve Myers)
Pull request description:
### Description
fixes#1112
Simple function renaming plus updated docs:
1. electrum_ext: rename functions `scan_without_keychain` to `sync` and `scan` to `full_scan`
2. esplora_ext: rename functions `scan_txs` to `sync` and `scan_txs_with_keychains` to `full_scan`
### Notes to the reviewers
The esplora_ext changes were partially fixed in #1070 but I renamed again so the functions match names ~~suggested in #1112~~ agreed on in discord poll, `sync` and `full_scan`.
### Changelog notice
Changed
- electrum_ext: rename functions scan_without_keychain to sync and scan to full_scan
- esplora_ext: rename functions scan_txs to sync and scan_txs_with_keychains to full_scan
### 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: d34516ecc513a194b679f73a1260d0cbc3d12b6a2e162d822e7381da0b3250aff319e85ed2fadec506e36f95a78a5cd79d0ab972da2b02928c074be17664da08
Now that the deprecated `get_checksum{,_bytes}` routines are removed,
the checksum is always computed with ignored data after the first '#',
i.e. the boolean parameter `exclude_hash` is not needed anymore and
the functionality can be consolidated into `calc_checksum_bytes`.
1def76f1f17fc876534c798883099c58de57c0fd chore: make clippy happy and bump clippy msrv (志宇)
c9467dcbb27bd497006846dcfcefb0c2cf8823c4 chore: improve documentation of lookahead (LLFourn)
bc796f412acdc3d2cd96f7aec0f24fa47c1fe889 fix(example): bitcoind_rpc_polling now initializes local_chain properly (志宇)
4fd539b6470f7f771e3b5e09e3287952fa7a1825 feat(chain)!: `KeychainTxOutIndex` uses a universal lookahead (Antoine Poinsot)
Pull request description:
### Description
The `bdk::Wallet` is currently created without setting any lookahead value for the keychain. This implicitly makes it a lookahead of 0. As this is a high-level interface we should avoid footguns and aim for a reasonable default.
To fix this, we have also decided to change `KeychainTxOutIndex` to have a default lookahead. Additionally, we have simplified the `KeychainTxOutIndex` API to have a single `lookahead` that is ONLY set at construction `KeychainTxOutIndex::new(lookahead: u32) -> Self`. This avoids the footguns of having methods which allows the caller to decrease the `lookahead` (which will panic).
### Notes to the reviewers
~A way to set this value externally is introduced in #1172. This PR only aims to use a saner default than 0. `1_000` is the value used by the Bitcoin Core wallet, and that seems reasonable to me.~
Edit: we should NOT allow setting the `lookahead` value after-the-fact. Instead, the `lookahead` should be provided to the wallet's constructor.
@evanlinjin: I don't think additional tests are necessary as no additional features are added, and the surface area of the API is decreased. The original tests already thoroughly test the `lookahead` concept.
### Checklists
#### All Submissions:
*(This section was updated as this PR changed from being a simple setting to introducing a new method.)*
* [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
~* [ ] I've added tests~
* [x] I've added docs
ACKs for top commit:
LLFourn:
ACK 1def76f1f17fc876534c798883099c58de57c0fd
Tree-SHA512: b4c3be8a4f2ac4877cf3f05852147e7dd1daeb02d3bc40895f02fd2a58e584f1dc0735b524153ff0875380ac93c0b4c31e516873d7a9b0027fdbbb5fe7970ff2
The wallet is currently created without setting any lookahead value for
the keychain. This implicitly makes it a lookahead of 0. As this is a
high-level interface we should avoid footguns and aim for a reasonable
default.
Instead of simply patching it for wallet, we alter `KeychainTxOutIndex`
to have a default lookahead value. Additionally, instead of a
per-keychain lookahead, the constructor asks for a `lookahead` value.
This avoids the footguns of having methods which allows the caller the
decrease the `lookahead` (and therefore panicing). This also simplifies
the API.
Co-authored-by: Antoine Poisot <darosior@protonmail.com>
Co-authored-by: 志宇 <hello@evanlinjin.me>
f4863c6314904ddd5da586fed0abb8f04ccee396 fix(wallet): apply loaded changeset to indexed_graph (thunderbiscuit)
Pull request description:
### Description
This PR applies the tx_graph from the changeset when loading a wallet from persistence. This ensures among other things that the revealed keychain indices get picked up by the new wallet. A test for this has been added/modified from an old test.
### Notes to the reviewers
### Changelog notice
Fix: loading a wallet from persistence now restores keychain indices.
### 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
* [x] 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:
evanlinjin:
ACK f4863c6314904ddd5da586fed0abb8f04ccee396
Tree-SHA512: c8502077ba25e6fb953829b020b396774aa0569f7272e7818f30ddabed9d1d8ce791729bebc92b9ec1059028399495cb79ea147cf900f25aace94045dd7290a6
e7fbc8bcf36de110e88095dba8be0c62e2c8e0ef ci: run clippy_check with rust stable (Steve Myers)
2251b8d41661deb5d8ef7b98abef55efe6437180 ci: pin home version to 0.5.5 for 1.63 MSRV (Steve Myers)
Pull request description:
### Description
Fixed 1.63 MSRV error by pinning `home` dependency to `0.5.5`, and `clippy` error by changing `check_clippy` job to using rust `stable` version.
### Notes to the reviewers
It's OK to use rust `stable` version for clippy because we already have a `clippy.toml` file to tell it which version of the clippy rules to check against.
### Changelog notice
None
### 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:
evanlinjin:
ACK e7fbc8bcf36de110e88095dba8be0c62e2c8e0ef
Tree-SHA512: 4e9e12488d44a940ea80ecc32ae74dade13d04d5088cb2206271401a2d77b56407af36482df952354b187a52b83631dcdf53bd60d9084a910f4be278059df93b
0adff9c35f109a15740212b4dce74c03950c85ed doc: Improve TxGraph & co docs (Daniela Brozzoni)
Pull request description:
### 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:
Re-ACK 0adff9c35f109a15740212b4dce74c03950c85ed
Tree-SHA512: 83adffeddf6c8ddb7b5e57a0fa2e5cffaf75cdeea59be0a6c5e94dcd5a7f98328db8e2a620edc753e60ea3382282908c75d34783a280348cfd105a37982c762b
169385bb5ba0fe6ad3ed4fbbad431904582c7eb7 ci: change MSRV to 1.63.0 (Steve Myers)
Pull request description:
### Description
fixes#331
### Notes to the reviewers
We won't merge this PR until LDK merges lightningdevkit/rust-lightning#2681.
There are alot of clippy checks to fix at 1.63.0 so I left the clippy MSRV at 1.57.0 for now.
### Changelog notice
Changed
- MSRV is now 1.63.0 for bdk, chain, and bitcoind_rpc crates
### 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:
evanlinjin:
ACK 169385bb5ba0fe6ad3ed4fbbad431904582c7eb7
Tree-SHA512: ad69038173b4f050b57f637fc06a4153cf76929992cfea77e3f25d1e66be102bd2f83a46401a7e3245e9cc54602210c95b75a578f18c5c8b55d1e7229e92197f
0ecc0280c032301dc638e75e54a8691d66d50274 doc(bdk): Clarify the absolute_fee, fee_rate docs (Daniela Brozzoni)
Pull request description:
Fixes#1066
### 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:
ACK 0ecc0280c032301dc638e75e54a8691d66d50274
Tree-SHA512: 152e48b86c21d4fad711abf76dd8fdc0e8955030331005c1ba6ff0c866c52870161f91ec740838f8238c5ad1c620e06212099308a55d130699cb18e4666e3f3f
6817ca9bcbff957efb58f96886a30b6bd87c0cde ci: pin hyper-rustls version to 0.24.0 for 1.57 MSRV (thunderbiscuit)
4ee41dbc402121d14ffa099863bf35329851c1e4 build(esplora): Add async-https-rustls flag to esplora client (thunderbiscuit)
Pull request description:
### Description
The bdk_esplora crate currently doesn't expose the [`async-https-rustls` flag offered by the rust-esplora-client](ef1925e1ee/Cargo.toml (L44)) crate and instead requires users to build using the `default-tls` flag on reqwest, which uses the platform-specific openssl library when compiling. This creates complications for cross-compilation, notably for our Android builds that currently support 3 architectures (`arm64-v8a`, `armeabi-v7a`, and `x86_64`). In order to solve this we can either compile the openssl libraries for each of the platforms we want to support, or use the rustls-tls version of reqwest. The second options is much easier and requires less fiddling with the internals of the Android native development kit and cross-compilation rabbit holes.
Before we merge this I want to make sure I understand the tradeoffs between the `native-tls` and the `rustls-tls` and confirm that there are not potential issues there, but from what I understand they should provide the same functionality/security, and because these are already available/exposed in reqwest and rust-esplora-client, I think this should be a fairly straightforward additional feature we offer.
### Changelog notice
```txt
Added:
- New async-https-rustls feature flag for the bdk_esplora crate, allowing to compile rust-esplora-client using rustls-tls instead of the default native-tls.
```
### 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:
ACK 6817ca9bcbff957efb58f96886a30b6bd87c0cde
realeinherjar:
ACK 6817ca9bcb
danielabrozzoni:
ACK 6817ca9bcbff957efb58f96886a30b6bd87c0cde
Tree-SHA512: 1d417da7cf85e157d71f56442a06e817e8741822d7bff9089f7fbb70ff8b4854f1f52befbc348b849e9c98cae848b792d426cd5bf551e7a9089b15467d28efdd
43aed386bc33f8dfca53ea2ec166dea1ce3d42d3 esplora: also test the gap limit bounds in the async client (Antoine Poinsot)
cb713e5b8c74181518e8cfcd4095c862bc73f014 esplora: also fix the gap limit check in the async client (Antoine Poinsot)
2c4e90a76fea51cb7381242f55b1ca0f02e20d4e esplora: scan gap limit bounds testing (Antoine Poinsot)
18bd3296170e64aee6870cd96dde52a0078bbcb1 esplora: fix incorrect gap limit check in blocking client (Antoine Poinsot)
Pull request description:
The gap limit was checked such as if the last_index was not None but the last_active_index was, we'd consider having reached it. But the last_index is never None for this check. This effectively made it so the gap limit was always 1: if the first address isn't used last_active_index will be None and we'd return immediately.
Fix this by avoiding error-prone Option comparisons and correctly checking we've reached the gap limit before breaking out of the loop.
ACKs for top commit:
danielabrozzoni:
ACK 43aed386bc33f8dfca53ea2ec166dea1ce3d42d3
evanlinjin:
ACK 43aed386bc33f8dfca53ea2ec166dea1ce3d42d3
Tree-SHA512: c6a172e0627380add56aec79e7fe36c0358e092b59f0bea8885d3524e65c10336291943efe6aeb5cc83f90c4f2146ed63215e56e08583d703b6ab57284487f03
The gap limit was checked such as if the last_index was not None but the
last_active_index was, we'd consider having reached it. But the
last_index is never None for this check. This effectively made it so the
gap limit was always 1: if the first address isn't used
last_active_index will be None and we'd return immediately.
Fix this by avoiding error-prone Option comparisons and correctly
checking we've reached the gap limit before breaking out of the loop.
278210bb8918923005e80968df3dfcc3372c0a5c docs(bdk): clarify `insert_txout` docs (志宇)
6fb45d8a735ec8db9142489d86107de192e0fa9c test(bdk): add `test_list_output` (志宇)
e803ee901002cae4db5ebf3544eb42c6cf81e5e2 feat(bdk): add `Wallet::list_output` method (志宇)
82632897aaa4ea0ac24803f58fbd13d6dc9c4357 refactor(bdk)!: rename `LocalUtxo` to `LocalOutput` (志宇)
Pull request description:
Fixes#1184
### Description
Introduce `Wallet::list_output` method that lists all outputs (both spent and unspent) in a consistent history.
### Changelog notice
- Rename `LocalUtxo` to `LocalOutput`.
- Add `Wallet::list_output` method.
### 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
ACKs for top commit:
notmandatory:
re-ACK 278210bb8918923005e80968df3dfcc3372c0a5c
danielabrozzoni:
ACK 278210bb8918923005e80968df3dfcc3372c0a5c
Tree-SHA512: 151af0e05e55d9c682271ef0c7a82e189531db963f65aa62c2ba0507f203dde39ab7561521c56e72c26830828e94ff96b7bd7e3f46082b23f79c5e0f89470136
