96a9aa6e63474dbd93a2ef969eef5b07c79e6491 feat(chain): refactor `merge_chains` (志宇)
2f22987c9e924800f8682b2dcbdde60fd26b069a chore(chain): fix comment (志宇)
daf588f016ec3118c875db8ed6b55fa03683f0f6 feat(chain): optimize `merge_chains` (志宇)
77d35954c1f3a18f767267e9097f63ca11c709ec feat(chain)!: rm `local_chain::Update` (志宇)
1269b0610efb7bd86d92a909800f9330568c797a test(chain): fix incorrect test case (志宇)
72fe65b65f297ebb7160eee6859c46e29c2d9528 feat(esplora)!: simplify chain update logic (志宇)
eded1a7ea0c6a4b9664826df4f77b714cbad0bcc feat(chain): introduce `CheckPoint::insert` (志宇)
519cd75d23fbb72321b0b189dca12afbfd78c0c7 test(esplora): move esplora tests into src files (志宇)
a6e613e6b978b995abf6c92a16df0300b113aa2c test(esplora): add `test_finalize_chain_update` (志宇)
494d253493f1bc914adba16a28ccf1bc0a0f4ec8 feat(testenv): add `genesis_hash` method (志宇)
886d72e3d541d088320bbdad6804057f32aca684 chore(chain)!: rm `missing_heights` and `missing_heights_from` methods (志宇)
bd62aa0fe199d676710c9909617198d62f4897c0 feat(esplora)!: remove `EsploraExt::update_local_chain` (志宇)
1e997939837e9c1f0c087d6d28ac12e373c8c05f feat(testenv): add `make_checkpoint_tip` (志宇)
Pull request description:
Fixes#1354
### Description
Built on top of both #1369 and #1373, we simplify the `EsploraExt` API by removing the `update_local_chain` method and having `full_scan` and `sync` update the local chain in the same call. The `full_scan` and `sync` methods now takes in an additional input (`local_tip`) which provides us with the view of the `LocalChain` before the update. These methods now return structs `FullScanUpdate` and `SyncUpdate`.
The examples are updated to use this new API. `TxGraph::missing_heights` and `tx_graph::ChangeSet::missing_heights_from` are no longer needed, therefore they are removed.
Additionally, we used this opportunity to simplify the logic which updates `LocalChain`. We got rid of the `local_chain::Update` struct (which contained the update `CheckPoint` tip and a `bool` which signaled whether we want to introduce blocks below point of agreement). It turns out we can use something like `CheckPoint::insert` so the chain source can craft an update based on the old tip. This way, we can make better use of `merge_chains`' optimization that compares the `Arc` pointers of the local and update chain (before we were crafting the update chain NOT based on top of the previous local chain). With this, we no longer need the `Update::introduce_older_block` field since the logic will naturally break when we reach a matching `Arc` pointer.
### Notes to the reviewers
* Obtaining the `LocalChain`'s update now happens within `EsploraExt::full_scan` and `EsploraExt::sync`. Creating the `LocalChain` update is now split into two methods (`fetch_latest_blocks` and `chain_update`) that are called before and after fetching transactions and anchors.
* We need to duplicate code for `bdk_esplora`. One for blocking and one for async.
### Changelog notice
* Changed `EsploraExt` API so that sync only requires one round of fetching data. The `local_chain_update` method is removed and the `local_tip` parameter is added to the `full_scan` and `sync` methods.
* Removed `TxGraph::missing_heights` and `tx_graph::ChangeSet::missing_heights_from` methods.
* Introduced `CheckPoint::insert` which allows convenient checkpoint-insertion. This is intended for use by chain-sources when crafting an update.
* Refactored `merge_chains` to also return the resultant `CheckPoint` tip.
* Optimized the update `LocalChain` logic - use the update `CheckPoint` as the new `CheckPoint` tip when possible.
### 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:
LLFourn:
ACK 96a9aa6e63474dbd93a2ef969eef5b07c79e6491
Tree-SHA512: 3d4f2eab08a1fe94eb578c594126e99679f72e231680b2edd4bfb018ba1d998ca123b07acb2d19c644d5887fc36b8e42badba91cd09853df421ded04de45bf69
`merge_chains` now returns a tuple of the resultant checkpoint AND
changeset. This is arguably a more readable/understandable setup.
To do this, we had to create `CheckPoint::apply_changeset` which is kept
as a private method.
Thank you @ValuedMammal for the suggestion.
Co-authored-by: valuedvalued mammal <valuedmammal@protonmail.com>
d3a14d411d2a1a37f07e42c28eae3a1836aec14d fix: enable blocking-https-rustls feature on esplora client (thunderbiscuit)
Pull request description:
The [`blocking` feature on the rust-esplora-client library](https://github.com/bitcoindevkit/rust-esplora-client/blame/master/Cargo.toml#L35) changed from ureq to minreq, which does not come with https enabled by default, breaking previously working code that simply enabled the `blocking` feature on the `bdk_esplora` crate.
This change will enable what is currently the "default https" [flag for the minreq library](https://docs.rs/minreq/latest/minreq/#https-or-https-rustls) when using the `blocking` feature on bdk_esplora, reverting that breaking change.
### Notes to the reviewers
Another way we could do this (let me know if this is preferable) is to add a new feature called `blocking-https-rustls`:
```rust
blocking = ["esplora-client/blocking"]
blocking-https-rustls = ["esplora-client/blocking-https-rustls"]
```
### Changelog notice
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### 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
#### 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:
storopoli:
ACK d3a14d411d2a1a37f07e42c28eae3a1836aec14d
evanlinjin:
ACK d3a14d411d2a1a37f07e42c28eae3a1836aec14d
Tree-SHA512: d25495186ceba2fcd04bc9ff0aebfb32ac5db6885ef8e4df1e304c5ee5264f6161821e06d29367d2837afcc64a53f1553e7c0bb065e6a2e46dc08b8e04c2ad8e
d39b319ddf6bf3365d5d01841a8d366c6231db06 test(wallet): Test wallet addresses (valued mammal)
a266b4718f7839759a3e615805931041b67b8e91 chore(wallet)!: Remove enum AddressIndex (valued mammal)
d87874780b4a4c7be282381ae1102c028f3ae581 refactor(wallet)!: Remove method get_address (valued mammal)
d3763e5e37569cea0860217fba980ab0389e4e64 feat(wallet): Add new address methods (valued mammal)
Pull request description:
Improvements to the wallet address API, see commit messages for details.
### Notes to the reviewers
The logic of getting addresses is roughly the same as before when using `AddressIndex`, following this mapping:
- `New` -> `reveal_next_address`
- `LastUnused` -> `next_unused_address` (assuming this is what `LastUnused` really means)
- `Peek` -> `peek_address`
Wondering whether it makes sense to expose [`is_used`](358e842dcd/crates/chain/src/keychain/txout_index.rs (L236)) for Wallet as well.
fixes#898
### Changelog notice
Added:
- Added Wallet methods:
- `peek_address`
- `reveal_next_address`
- `next_unused_address`
- `reveal_addresses_to`
- `list_unused_addresses`
- `mark_used`
- `unmark_used`
Removed:
- Removed Wallet methods:
- `get_address`
- `get_internal_address`
- `try_get_address`
- `try_get_internal_address`
- Removed type AddressIndex
### Checklists
* [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
### Feature
* [x] I've added tests for the new feature
* [x] I've added docs for the new feature
* [x] This pull request breaks the existing API
* [x] I'm linking the issue being fixed by this PR
ACKs for top commit:
evanlinjin:
ACK d39b319ddf6bf3365d5d01841a8d366c6231db06
Tree-SHA512: ab7f3031f552ee6ea58ae4f3c5412bbedc0ea63e662fe9fa402de0f68a50448521be1e118e89f70bf970d5bf44ea1dc66bbeeff3e9312bae966bebd3072a7073
Introduce a new API for getting addresses from the Wallet that
reflects a similiar interface as the underlying indexer
`KeychainTxOutIndex` in preparation for removing `AddressIndex` enum.
Before this change, the only way to get an address was via the methods
`try_get{_internal}_address` which required a `&mut` reference to the
wallet, matching on the desired AddressIndex variant. This is too
restrictive since for example peeking or listing unused addresses
shouldn't change the state of the wallet. Hence we provide separate
methods for each use case which makes for a more efficient API.
e51af49ffa951e14203ac2b465ade351dd90f6cd fix(wallet): remove generic from wallet (Rob N)
Pull request description:
### Description
The `PersistenceBackend` uses generics to describe errors returned while applying the change set to the persistence layer. This change removes generics wherever possible and introduces a new public error enum. Removing the generics from `PersistenceBackend` errors is the first step towards #1363
*Update*: I proceeded with removing the generics from `Wallet` by introducing a `Box<dyn PersistenceBackend>` .
### Notes to the reviewers
This one sort of blew up in the number of changes due to the use of generics for most of the `Wallet` error variants. The generics were only used for the persistence errors, so I removed the generics from higher level errors whenever possible. The error variants of `PersistenceBackend` may also be more expressive, but I will level that up for discussion and make any changes required.
### Changelog notice
- Changed `PersistenceBackend` errors to depend on the `anyhow` crate.
- Remove the generic `T` from `Wallet`
### 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
#### Bugfixes:
* [x] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [x] I'm linking the issue being fixed by this PR
ACKs for top commit:
evanlinjin:
ACK e51af49ffa951e14203ac2b465ade351dd90f6cd
Tree-SHA512: 8ce4f1c495310e16145555f4a6a29a0f42cf8944eda68004595c3532580767f64f779185022147a00d75001c40d69fdf8f8de2d348eb68484b170d2a181117ff
fac228337c79e1a7c406500c177e049e7f9f5da7 feat(chain)!: make `KeychainTxOutIndex` more range based (LLFourn)
Pull request description:
KeychainTxOut index should try and avoid "all" kind of queries. There may be subranges of interest. If the user wants "all" they can just query "..".
The ideas is that KeychainTxOutIndex should be designed to be able to incorporate many unrelated keychains that can be managed in the same index. We should be able to see the "net_value" of a transaction to a specific subrange. e.g. imagine a collaborative custody service that manages all their user descriptors inside the same `KeychainTxOutIndex`. One user in their service may pay another so when you are analyzing how much a transaction is spending for a particular user you need to do analyze a particular sub-range.
### Notes to the reviewers
- I didn't change `unused_spks` to follow this rule because I want to delete that method some time in the future. `unused_spks` is being used in the examples for syncing but it shouldn't be (the discussion as to why will probably surface in #1194).
- I haven't applied this reasoning to the methods that return `BTreeMap`s e.g. `all_unbounded_spk_iters`. It probably should be but I haven't made up my mind yet.
This probably belongs after #1194
### Changelog notice
- `KeychainTxOutIndex` methods modified to take ranges of keychains instead.
### 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 fac228337c79e1a7c406500c177e049e7f9f5da7
Tree-SHA512: ec1e75f19d79f71de4b6d7748ef6da076ca92c2f3fd07e0f0dc88e091bf80c61268880ef78be4bed5e0dbab2572e22028f868f33e68a67d47813195d38d78ba5
The intention is to remove the `Update::introduce_older_blocks`
parameter and update the local chain directly with `CheckPoint`.
This simplifies the API and there is a way to do this efficiently.
Previously, we would update the `TxGraph` and `KeychainTxOutIndex`
first, then create a second update for `LocalChain`. This required
locking the receiving structures 3 times (instead of twice, which
is optimal).
This PR eliminates this requirement by making use of the new `query`
method of `CheckPoint`.
Examples are also updated to use the new API.
5f238d8e672047ac2766550aa3ed97e05e7b2531 Bump bdk version to 1.0.0-alpha.9 (Steve Myers)
Pull request description:
### Description
Bump bdk version to 1.0.0-alpha.9
bdk_chain to 0.12.0
bdk_bitcoind_rpc to 0.8.0
bdk_electrum to 0.11.0
bdk_esplora to 0.11.0
bdk_file_store to 0.9.0
bdk_testenv to 0.2.0
fixes#1399
### Notes to the reviewers
I also removed unneeded version for bdk_testenv in dev-dependencies, see https://github.com/bitcoindevkit/bdk/pull/1177#discussion_r1545945973.
### 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 5f238d8e672047ac2766550aa3ed97e05e7b2531
Tree-SHA512: 7ede94a6476a6b8c49a16b0aad147030eab23e26b9c4cadb1dd319fb8562ae325640f506f2d6dab0e85b0ee7f6955ac298ec1f70264704dc7f9a9492f8794f38
446b045161ebad3fbdf0ea96e8ff6f9da8ad212c test(chain): introduce proptest for `CheckPoint::range` (志宇)
Pull request description:
### Description
This is based on #1369. It made sense for me to introduce the `CheckPoint::range` test as a proptest. I think we should also start introducing it for other methods too.
### Changelog notice
* Added proptest for `CheckPoint::range`.
### 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
Top commit has no ACKs.
Tree-SHA512: 2d8aad5a1ad152413fbc716fed4a47ad621e723928c5331728da2fbade995ebd677acfa05d2e7639d74d0f66e0971c72582d9cd562ea008b012774057b480d62
Ensure that `CheckPoint::range` returns expected values by comparing
against values returned from a primitive approach.
I think it is a good idea to start writing proptests for this crate.
a2a64ffb6e92baf46a912f36294f3f4f521a528a fix(electrum)!: Remove `seen_at` param from `into_tx_graph` (valued mammal)
37fca35ddede6cbc9d9428a2722eff82a405b1b2 feat(tx_graph): Add method update_last_seen_unconfirmed (valued mammal)
Pull request description:
A method `update_last_seen_unconfirmed` is added for `TxGraph` that allows inserting a `seen_at` time for all unanchored transactions.
fixes#1336
### Changelog notice
Changed:
- Methods `into_tx_graph` and `into_confirmation_time_tx_graph`for `RelevantTxids` are changed to no longer accept a `seen_at` parameter.
Added:
- Added method `update_last_seen_unconfirmed` for `TxGraph`.
### 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 a2a64ffb6e92baf46a912f36294f3f4f521a528a
Tree-SHA512: 9011e63314b0e3ffcd50dbf5024f82b365bab1cc834c0455d7410b682338339ed5284caa721ffc267c65fa26d35ff6ee86cde6052e82a6a79768547fbb7a45eb
Upgrade:
- bitcoin to v0.31.0
- miniscript to v11.0.0
Note: The bitcoin upgrade includes improvements to the
`Transaction::weight()` function, it appears those guys did good, we
no longer need to add the 2 additional weight units "just in case".
and `into_confirmation_time_tx_graph`, since now it makes
sense to use `TxGraph::update_last_seen_unconfirmed`.
Also, use `update_last_seen_unconfirmed` in examples for
electrum/esplora. We show how to update the last seen
time for transactions by calling `update_last_seen_unconfirmed`
on the graph update returned from a blockchain source, passing
in the current time, before applying it to another `TxGraph`.
That accepts a `u64` as param representing the latest timestamp
and internally calls `insert_seen_at` for all transactions in
graph that aren't yet anchored in a confirmed block.
53942cced492138174638a8087b08f643a8d41ad chore(chain)!: rm `From<LocalChain> for BTreeMap<u32, BlockHash>` (志宇)
2d1d95a6850a5bab9c5bf369a498fe090852cd93 feat(chain): impl `PartialEq` on `CheckPoint` (志宇)
9a62d56900a33a519dd0165ccdb91711917772f3 feat(chain): add `get` and `range` methods to `CheckPoint` (志宇)
Pull request description:
Partially fixes#1354
### Description
These methods allow us to query for checkpoints contained within the linked list by height and height range. This is useful to determine checkpoints to fetch for chain sources without having to refer back to the `LocalChain`.
Currently this is not implemented efficiently, but in the future, we will change `CheckPoint` to use a skip list structure.
### Notes to the reviewers
Please refer to the conversation in #1354 for more details. In summary, both `TxGraph::missing_heights` and `tx_graph::ChangeSet::missing_heights_from` are problematic in their own ways. Additionally, it's a better API for chain sources if we only need to lock our receiving structures twice (once to obtain initial state and once for applying the update). Instead of relying on methods such as `EsploraExt::update_local_chain` to get relevant checkpoints, we can use these query methods instead. This allows up to get rid of `::missing_heights`-esc methods and remove the need to lock receiving structures in the middle of the sync.
### Changelog notice
* Added `get` and `range` methods to `CheckPoint` (and in turn, `LocalChain`). This simulates an API where we have implemented a skip list of checkpoints (to implement in the future). This is a better API because we can query for any height or height range with just a checkpoint tip instead of relying on a separate checkpoint index (which needs to live in `LocalChain`).
* Changed `LocalChain` to have a faster `Eq` implementation. We now maintain an xor value of all checkpoint block hashes. We compare this xor value to determine whether two chains are equal.
* Added `PartialEq` implementation for `CheckPoint` and `local_chain::Update`.
### 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:
LLFourn:
ACK 53942cced492138174638a8087b08f643a8d41ad
Tree-SHA512: 90ef8047fe1265daa54c9dfe8a8c520685c898a50d18efd6e803707fcb529d0790d20373c9e439b9c7ff301db32b47453020cae7db4da2ea64eba895aa047f30
I don't think this was ever used. The only possible usecase I can think
of is for tests, but I don't think that is a strong enough incentive for
us to keep this.
These methods allow us to query for checkpoints contained within the
linked list by height and height range. This is useful to determine
checkpoints to fetch for chain sources without having to refer back to
the `LocalChain`.
Currently this is not implemented efficiently, but in the future, we
will change `CheckPoint` to use a skip list structure.
798ed8ced25156049126645435127a22245e916f fix: remove deprecated `max_satisfaction_weight (Jose Storopoli)
Pull request description:
### Description
Continuation of #1115.
Closes#1036.
* Change deprecated `max_satisfaction_weight` to `max_weight_to_satisfy`
* Remove `#[allow(deprecated)]` flags
### Notes to the reviewers
I've changed all `max_satisfaction_weight()` to `max_weight_to_satisfy()` in `Wallet.get_available_utxo()` and `Wallet.build_fee_bump()`. Checking the docs on the `miniscript` crate for `max_weight_to_satisfy` has the following note:
We are testing if the underlying descriptor `is.segwit()` or `.is_taproot`,
then adding 4WU if true or leaving as it is otherwise.
Another thing, we are not testing in BDK tests for legacy (pre-segwit) descriptors.
Should I also add them to this PR?
### Changelog notice
### Fixed
Replace the deprecated `max_satisfaction_weight` from `rust-miniscript` to `max_weight_to_satisfy`.
### 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
* [x] I'm linking the issue being fixed by this PR
ACKs for top commit:
evanlinjin:
ACK 798ed8ced25156049126645435127a22245e916f
Tree-SHA512: 60babecee13c24915348ddb64894127a76a59d9421d52ea37acc714913685d57cc2be1904f9d0508078dd1db1f7d7dad83a734af5ee981801ca87de2e9984429
8ab58af093ff295b86c3f8189aa96dea313092c4 feat(chain)!: wrap `TxGraph` txs with `Arc` (志宇)
Pull request description:
### Description
This PR makes `TxGraph` store transactions as `Arc<Transaction>`.
`Arc<Transaction>` can be shared between the chain-source and receiving structures. This allows the chain-source to keep the already-fetched transactions (save bandwith) and have a shared pointer to the transaction (save memory).
Our current logic to avoid re-fetching transactions is to refer back to the receiving structures. However, this means an additional round of locking our receiving structures.
### Notes to the reviewers
This will make more sense once I update the esplora/electrum chain sources to make use of both #1369 and this PR. The result would be chain sources which would only require locking the receiving structures twice (once for initiating the update, and once for applying the update).
### Changelog notice
* Changed `TxGraph` to store transactions as `Arc<Transaction>`. This allows chain-sources to cheaply keep a copy of already-fetched transactions.
### 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:
LLFourn:
ACK 8ab58af093ff295b86c3f8189aa96dea313092c4
notmandatory:
ACK 8ab58af093ff295b86c3f8189aa96dea313092c4
Tree-SHA512: 81d7ad35fed7f253a3b902f09a41aaef2877f6201d4f6e78318741bf00e4b898a8000d878ffcbfe75701094ce3e9021bd718b190a655331a9e11f0ad66bdb02f
7b97c956c7abdd6415ccdda79c26cf212e15cb4e Bump bdk version to 1.0.0-alpha.8 (Steve Myers)
Pull request description:
### Description
Bump versions:
bdk version to 1.0.0-alpha.8
bdk_bitcoind_rpc to 0.7.0
bdk_electrum to 0.10.0
bdk_esplora to 0.10.0
bdk_file_store to 0.8.0
bdk_hwi to 0.2.0
fixes#1388
### 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 7b97c956c7abdd6415ccdda79c26cf212e15cb4e
Tree-SHA512: 32286f33f8fe595f79ef6b9450c7906dee15b5c93ad62435025f4fb1446f9ee8c6147190d628b95e21b8f36c02ca3f8b86b8a5e8cab3835773750967f9e36489
25800139124a37608c9da0a6ad76c22795f110d6 chore(testenv): fix cargo manifest (志宇)
Pull request description:
### Description
This will make the `bdk_testenv` crate actually publishable.
### Changelog notice
* Fix cargo manifest of `bdk_testenv`.
### 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:
LLFourn:
ACK 25800139124a37608c9da0a6ad76c22795f110d6
Tree-SHA512: 52707450473713490cb1115af06747dc4d6f78cf4bf877cd3a246064af11786b5a89829731e911ffba19a71db9b19a60ad5b12f20871d57b296427761707d826
7c1861aab9a76f2ba4a2ae372a16c9669a33f5de fix: define and document `stop_gap` (Jose Storopoli)
Pull request description:
### Description
- changes the code implementation to "the maximum number of consecutive unused addresses" in esplora async and blocking extensions.
- for all purposes treats `stop_gap = 0` as `stop_gap = 1`.
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap limit is reached and not go further in `full_scan`, as suggested in https://github.com/bitcoindevkit/bdk/issues/1227#issuecomment-1859040463
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other Bitcoin-related software.
Closes#1227.
### Notes to the reviewers
We can iterate over the wording and presentation of the `stop_gap` definition
and details.
### Changelog notice
- BREAKING: change `stop_gap` definition and effects in `full_scan`
to reflect the common definitions in most Bitcoin-related software.
### 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
#### Bugfixes:
* [x] This pull request breaks the existing API
* [x] I've added tests to reproduce the issue which are now passing
* [x] I'm linking the issue being fixed by this PR
ACKs for top commit:
notmandatory:
ACK 7c1861aab9a76f2ba4a2ae372a16c9669a33f5de
Tree-SHA512: d9bc5f8ebace47fa33f023ceddb3df5629ad3e7fa130a407311a0303ac59810e6527254efb9075f9e87bf37bec8655c4726eb9cb99f6b038fbeb742f79e995c0
- changes the code implementation to "the maximum number of consecutive unused addresses"
in esplora async and blocking extjensions.
- treat `stop_gap = 0` as `stop_gap = 1` for all purposes.
- renames `past_gap_limit` to `gap_limit_reached` to indicate we want to break once the gap
limit is reached and not go further in `full_scan`, as suggested in
https://github.com/bitcoindevkit/bdk/issues/1227#issuecomment-1859040463
- change the tests according to the new implementation.
- add notes on what `stop_gap` means and links to convergent definition in other
Bitcoin-related software.
Closes#1227
Wrapping transactions as `Arc<Transaction>` allows us to share
transactions cheaply between the chain-source and receiving structures.
Therefore the chain-source can keep already-fetched transactions (save
bandwidth) and have a shared pointer to the transactions (save memory).
This is better than the current way we do things, which is to refer back
to the receiving structures mid-sync.
Documentation for `TxGraph` is also updated.
7c9ba3cfc855dc0845476fe923dac4e47cb5c06a chore(electrum,testenv): move `test_reorg_is_detected_in_electrsd` (志宇)
2462e9041599f395673f9b14f0b618877832f099 chore(esplora): rm custom WASM target spec test dependency (志宇)
04d0ab5a978fbfd45a5c795f9142ff4a9ba29ee3 test(electrum): added scan and reorg tests Added scan and reorg tests to check electrum functionality using `TestEnv`. (Wei Chen)
4edf533b678cb21f4c29ded22692e607ff75e2cd chore: extract `TestEnv` into separate crate `TestEnv` is extracted into its own crate to serve as a framework for testing other block explorer APIs. (Wei Chen)
6e648fd5afa188290b05f8e050ba69fe5f8b80e4 chore: update MSRV dependency for nightly docs (Wei Chen)
Pull request description:
### Description
`TestEnv` is extracted into its own crate with `electrsd` support added so that `TestEnv` can also serve `esplora` and `electrum`.
The tests in the `esplora` crate have also been updated to use `TestEnv`.
The `tx_can_become_unconfirmed_after_reorg()` test in `test_electrum` suggests that the electrum issue where a reorged tx would be stuck at confirmed does not exist anymore.
### Notes to the reviewers
The code for `tx_can_become_unconfirmed_after_reorg()` was adapted from the same test in `bitcoind_rpc/test_emitter`. This electrum version of the test requires extra review, as I am uncertain if I used the API efficiently.
#### 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 7c9ba3cfc855dc0845476fe923dac4e47cb5c06a
Tree-SHA512: 36c6501e477abb7ae68073b6f4776f1f69f8964010ab758aa3677aae96df10f2cb632421872cacd73b37123d6db8a9dbefb5b6416e0dd524b712bf3fc56b7139
