Preserve insertion order of manually selected utxos if TxOrdering::Untouched#262
Conversation
Pull Request Test Coverage Report for Build 15949866545Details
💛 - Coveralls |
7f16781 to
b1436ae
Compare
TxOrdering::Untouched
b1436ae to
dde0b3e
Compare
Since our logic is meant to enforce the precedence of local utxos, it makes sense to keep the test, but I agree there could be a simpler, easy to maintain version of it. ValuedMammal/bdk_wallet@49b5cef |
ValuedMammal
left a comment
There was a problem hiding this comment.
For consistency with the rest of the codebase I want to stick with the "UTXO" style acronym.
048daa6 to
d6d204b
Compare
|
Thanks for the review! |
oleonardolima
left a comment
There was a problem hiding this comment.
utACK
I left a question and a single nit, but overall it looks good to me! Agree with the new version of test suggested by VM's, it looks much better.
When TxBuilder::ordering is TxOrdering::Untouched, the insertion order of recipients and manually selected UTxOs should be preserved in transaction's output and input vectors respectively. Fixes bitcoindevkit#244
d6d204b to
0522114
Compare
…quired UTXOs first 8a5e763 test(tx_builder): Add `test_add_utxo_final_outpoint_retained` (valued mammal) 0b5d927 test(wallet): Add `test_tx_ordering_untouched_preserves_insertion_ordering_bnb_success` (valued mammal) e020391 fix(coin_selection): `calculate_cs_result` returns the required UTXOs first (valued mammal) Pull request description: ### Description Follow-up to #262 that addresses transaction input ordering when BnB finds a solution. Previously `calculate_cs_result` produced a CoinSelectionResult by appending the required UTXOs onto the selected ones, which changed the expected order of transaction inputs. `calculate_cs_result` now returns the required UTXOs before the newly selected ones. This behavior aligns with the expectation that the order of manually selected inputs should be preserved in the final transaction whenever `TxOrdering::Untouched` is specified. For related discussion refer to #244 (comment). ### Changelog notice Fixed - wallet: Fixed order of selected UTXOs for `BranchAndBoundCoinSelection`, required UTXOs come first ### Checklists #### All Submissions: * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) #### Bugfixes: * [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: 110CodingP: ACK [`8a5e763`](8a5e763). Tree-SHA512: 4ebf33f7d1fe6e6dcfff89e218aeefcec92ae8ae78c2589d7f496b433991122f48100be38ffa52b8fc2d67feb679d567a707dea8681810167eac1a6a04f9dcc0
Description
On my attempt to fix bitcoindevkit/bdk#1794 in bitcoindevkit/bdk#1798, I broke the assumption that insertion order is preserved when
TxBuilder::orderingisTxOrdering::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
Vecto store the manually selected UTxOs.I was reluctant to do it in this way because
HashMapseems a better solution giving its property of avoiding duplicates, but as we also want to keep the secuential nature of the insertion of UTxOs inTxBuilder, 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_outpointtest_prexisting_local_utxo_have_precedence_over_foreign_utxo_with_same_outpointMotivated 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_utxointerface.In this case it was expected for any
LocalUtxoof 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
cargo +nightly fmtandcargo clippybefore committing