You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge #262: Preserve insertion order of manually selected utxos if TxOrdering::Untouched
0522114 test(tx_builder): update precedence check of local UTXOs over add_foreign_utxos (valued mammal)
73bef28 doc(tx_builder): add info about manually selected UTxOs priority (nymius)
3316236 fix(tx_builder): preserve insertion order with TxOrdering::Untouched (nymius)
Pull request description:
### Description
On my attempt to fixbitcoindevkit/bdk#1794 in bitcoindevkit/bdk#1798, I broke the assumption that insertion order is preserved when `TxBuilder::ordering` is `TxOrdering::Untouched`. Some users are relying in this assumption, so here I'm trying to restore it back, without adding a new dependency for this single use case like #252, or creating a new struct just to track this.
In this fourth alternative solution I'm going back to use `Vec` to store the manually selected UTxOs.
I was reluctant to do it in this way because `HashMap` seems a better solution giving its property of avoiding duplicates, but as we also want to keep the secuential nature of the insertion of UTxOs in `TxBuilder`, here is an alternative aligned with that principle.
May replace #252
May replace #261 .
Fixes#244
### Notes to the reviewers
Also, as I was working on this, I came back to the following tests:
- `test_prexisting_foreign_utxo_have_no_precedence_over_local_utxo_with_same_outpoint`
- `test_prexisting_local_utxo_have_precedence_over_foreign_utxo_with_same_outpoint`
Motivated during the implementation and review of bitcoindevkit/bdk#1798.
Which required the underlying structure to also hold the properties of no duplication for manually selected UTxOs, as the structures were accessed directly for these cases.
The test tries to cover the case when there are two wallets using the same descriptor, one tracks transactions and the other does not. The first passes UTxOs belonging to the second one and this one creates transactions using the `add_foreign_utxo` interface.
In this case it was expected for any `LocalUtxo` of the offline wallet to supersede any conflicting foreign UTxO. But, the simulation of this case went against the borrowing constraints of rust.
By how costly was to reproduce this behavior for me in the tests, I would like to have second opinions in the feasibility of the test case.
### Changelog notice
No public APIs are changed by these commits.
### Checklists
> [!IMPORTANT]
> This pull request **DOES NOT** break the existing API
* [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 +nightly fmt` and `cargo clippy` before committing
* [x] I've added tests for the new code
* [x] I've expanded docs addressing new code
* [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:
ValuedMammal:
reACK 0522114
oleonardolima:
ACK 0522114
Tree-SHA512: f2726d75eab83e28cc748ac5cd6bd0c7f3dddb409ac61baf7d0a7030ddf81c11b10dbd5b18e8ac3d29a6afb4b8f29ee9a88f83094aebec771fdb4da2cd718326
0 commit comments