Feat/coin selection strategies - #151
Conversation
e3ca307 to
f77c5cc
Compare
| use crate::client::{Recipient, RecipientAddress}; | ||
|
|
||
| /// Upper bound on branch-and-bound iterations (see `bdk_coin_select` README). | ||
| const BNB_MAX_ROUNDS: usize = 10_000; |
There was a problem hiding this comment.
Hi, thanks for the review, 100_000 is indeed the value set in the example of the README of the coin_select project. It felt huge to me especially for the numbers of outputs we expect our users to have at once on a mobile hot wallet, so I decided to try 10_000, which already seems vastly overkill. Of course open to any rationale to set it to another value.
There was a problem hiding this comment.
100,000 is the default in bitcoin-core as well as rust-bitcoin-coinselection and also BDK coin_select as you mention. Setting it to less than that means you just get worse results. IE might not find the optimal solution.
It felt huge to me especially for the numbers of outputs we expect our users to have at once on a mobile hot wallet, so I decided to try 10_000
Have you tried bench-marking to see how it performs? There are some benchmarks you could try in bdk coin_select. I found the benchmarks in rust-bitcoin-coinselect to be much faster although I haven't investigated closely as to why.
There was a problem hiding this comment.
especially for the numbers of outputs we expect our users to have at once
Also, if you expect not many outputs, this is a non-issue, since that means BnB would simply run for less than 100,000 iterations since it would run out of combinations before hitting the iteration limit.
There was a problem hiding this comment.
Lastly, if you don't care about optimal results, and just want the fastest performance, you could ditch BnB and use SRD instead :)
Selecting in the pool's arbitrary order can leave a sub-dust excess (e.g. a single big utxo barely covering the payment), forcing the remainder into the fee although a change-creating selection exists. Selecting smallest-first minimizes the excess, so the greedy fallback produces a change output whenever one can be created.
2 participants
No description provided.