silent payments: use select coins algo - #74
Conversation
ce07773 to
fd0cffa
Compare
|
marking as draft while I run some local tests. |
01f9032 to
2dada94
Compare
The current behavior of hard-coding the long_term_fee_rate to be 1 can result in incorrect coin-selection behavior.
bb3be70 to
18938c1
Compare
In bitcoin-core, long-term-feerate is set on the command line using the flag consolidate_feerate, and then changed to long_term_fee_rate in spend.cpp before calling coin-selection algorithms. ref: https://github.com/bitcoin/bitcoin/blob/32ddfc92d9fdad40880f4c1aa3ad8884d3c8981a/src/wallet/spend.cpp#L1083 The text was also copied verbatim (besides units) from the bitcoin-core client. ref: https://github.com/bitcoin/bitcoin/blob/32ddfc92d9fdad40880f4c1aa3ad8884d3c8981a/src/wallet/init.cpp#L52 Lastly, the default was set to match that of bitcoin-core (10 sats/vB) ref: https://github.com/bitcoin/bitcoin/blob/32ddfc92d9fdad40880f4c1aa3ad8884d3c8981a/src/wallet/init.cpp#L52
a0ee5c3 to
c075593
Compare
|
Removed from draft state. |
5e11b34 to
ad08132
Compare
|
I just realized that another nice thing that bitcoin-coin-select has is the ability to define a max_transaction weight. So BnB for example would not return a set that breaks the transaction weight max (400_000 wu). bdk_coin_select does not seem to have the smarts to do that from what I can tell. ref: https://docs.rs/bitcoin-coin-selection/0.8.5/bitcoin_coin_selection/fn.branch_and_bound.html |
rust-bitcoin-coin-selection: * Uses native rust-bitcoin FeeRate * Supports additional selection algos such as CoinGrinder * Has fuzz tests and benchmarking for performance measurements and stability.
ad08132 to
c8acd58
Compare
|
I don't want this to be taken the wrong way in that I appreciate your work on coin selection, which is potentially an underdeveloped part of the ecosystem, but it appears you are the only active contributor to the crate being added. Can you remind me again why exactly some of these algorithms cannot be upstreamed to BDK? In the case of BDK, they have a foundation and handful of developers, where if one developer steps down, there is not much of a risk of a crate going stale. Given that they also have a broad base of users, not only is there a stronger maintenance guarantee, your work is more likely to be used in production wallets. |
I agree, there is still a lot of work to develop this crate further. Hopefully as bitcoin/units-1.0 becomes a thing, I will have advanced this crate to be less underdeveloped. This also means finding more projects that I can help test with so as to know how best to build the API and tooling.
It would be possible with a lot of work for me to re-design the algorithm to work with BDK coin-select. In viewing their project, it seems that the design patters are somewhat divergent from bitcoin-core from whom many of these selection algorithms originate. I'm not saying it's not possible, it would just be a large time investment for me to re-write coin-grinder to fit. Indeed I do think they should implement coin-grinder since it is the default algorithm that is used by bitcoin-core when fees are high. As stated in the PR, since I've maintained this project since times before BDK, I think it is more advanced in many ways. If you compare bench-marking times for example, this crate far outperforms BDK. Not to mention, I have spent a lot of time to add fuzz tests, not to mention property tests. All that is to say, I could port work into BDK, although, BDK could also just as easily start helping me out with this crate as well.
I am the main contributor to this coin-selection crate, it is true. For some time during the pandemic Tibo from crypto garage did all the maintenance, although, as far as I know, he has since moved to a different organization, and so is not directly involved anymore. However, Murch helps with review from time to time, and he basically wrote the book on coin-selection as you may well know. My hope is that as this gets further developed and gains adoption, I may have more help, however even large popular crates routinely end up being maintained by only a small number of people unfortunately.
Bdk does have a broad user base even though as mentioned above, I feel like their crate has many gaps. However, I do hope they have success in their project. Often times its better for the ecosystem to have choices, and I'm happy to help with their project if I find a way that I think I could benefit. |
|
After reflecting a bit, it sounds like there is not much enthusiasm for me adding this here based on the above conversation. Thank you for allowing me the chance to do a bit of field testing with this crate though. Will close for now. |
|
Also I want to add I'm happy to help BDK, even if it's not of any benefit to me. I think that came out wrong. It's just that I have a lot of other things on my plate I want to work on, although if I can find a way to help their project I am happy to do so. |
@rustaceanrob Just a thought, but if you and or @pzafonte wanted to help me maintain the coin-selection crate, we could probably make it a rust-bitcoin project. It was originally intended to be moved to the rust-bitcoin org since it's inception. However, there hasn't been anyone in rust-bitcoin that has the experience or time to help me out with this, so it never moved there. |
High level overview of this PR:
As a follow up, it would be nice to internally estimate both FeeRate and LongTermFeeRate using mempool and blockchain data similar to bitcoin core