coinselection
fuzz harness into 3 targets (coinselection_bnb
, coinselection_knapsack
, coinselection_srd
). The goal is to be able to fuzz each algorithm separately (to avoid performance issues) and also all of them together.
coinselection
harness
#31870
coinselection
fuzz harness into 3 targets (coinselection_bnb
, coinselection_knapsack
, coinselection_srd
). The goal is to be able to fuzz each algorithm separately (to avoid performance issues) and also all of them together.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31870.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | janb84, marcofleon, zaidmstrr, maflcko |
Concept ACK | yancyribbens |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
SetBumpFeeDiscount
by brunoerg)If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
220-{
221+enum class CoinSelectionAlgorithm {
222+ BNB,
223+ SRD,
224+ KNAPSACK,
225+ ALL
nit: missing trailing comma.
Also, what is the point of combining them, when they are handled completely separate anyway?
ALL
option. I don’t see anything that needs all of them combined.
224+ KNAPSACK,
225+ ALL
226+};
227+
228+template<CoinSelectionAlgorithm Algorithm>
229+void FuzzCoinSelectionAlgorithm(const uint8_t* buffer, size_t size) {
std::span
for new code
302- auto result_knapsack = KnapsackSolver(group_all, target, change_target, fast_random_context, max_selection_weight);
303- if (result_knapsack) {
304- assert(result_knapsack->GetSelectedValue() >= target);
305- assert(result_knapsack->GetWeight() <= max_selection_weight);
306- result_knapsack->RecalculateWaste(coin_params.min_viable_change, coin_params.m_cost_of_change, coin_params.m_change_fee);
307- (void)result_knapsack->GetShuffledInputVector();
350+FUZZ_TARGET(coinselection_srd) {
351+ FuzzCoinSelectionAlgorithm<CoinSelectionAlgorithm::SRD>(std::span<const uint8_t>(buffer.data(), buffer.size()));
352+}
353+
354+FUZZ_TARGET(coinselection_knapsack) {
355+ FuzzCoinSelectionAlgorithm<CoinSelectionAlgorithm::KNAPSACK>(std::span<const uint8_t>(buffer.data(), buffer.size()));
0 FuzzCoinSelectionAlgorithm<CoinSelectionAlgorithm::KNAPSACK>(buffer);
nit: it is already a span,no?
coinselection_bnb
, coinselection_knapsack
, coinselection_srd
) which is fine, but for the combined test I can’t find any fuzz target there like coinselection
.
Hey, I’m reviewing this PR, as the description says that we can test each target separately, (
coinselection_bnb
,coinselection_knapsack
,coinselection_srd
) which is fine, but for the combined test I can’t find any fuzz target there likecoinselection
.
I just updated the description. I removed the coinselection
target, so there are 3 ones.
Code review ACK 9b293d031c941dc6af0c4274e43388c57c702047
Knapsack is quite a bit slower than the other two, so separating them out is probably a good idea.
Coverage for the three targets: coinselection_bnb coinselection_srd coinselection_knapsack
344+ (void)result_knapsack->GetShuffledInputVector();
345+ (void)result_knapsack->GetInputSet();
346+ // If the total balance is sufficient for the target and we are not using
347+ // effective values, Knapsack should always find a solution (unless the selection exceeded the max tx weight).
348+ if (total_balance >= target && subtract_fee_outputs && !HasErrorMsg(result_knapsack)) {
349+ assert(result_knapsack);
if
statement.
Previously the assert was exposed, now it is guarded by the same condition, making it dead code that the compiler will remove.
In other words: { if (a) assert(a); }
is equivalent to { }
.
Tested ACK ba82240
The change to fuzz each algorithm independently seems an okay idea. The implementation/separation in the code also makes it easier to read, review, and reason about.
I also wrote a review note on the PR to document my learning journey
reACK ba82240553ddd534287845e10bc76b46b45329fe
Only thing that changed since last review is the fix to #31870 (review). The order of the two checks has been switched but afaict it shouldn’t matter.
I’m curious if there should be any doc updates accompanying this change.
No, it’s a test-only change.
review ACK ba82240553ddd534287845e10bc76b46b45329fe 👐
Signature:
0untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
1RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
2trusted comment: review ACK ba82240553ddd534287845e10bc76b46b45329fe 👐
3AaLQ7VClMZd8vRGNIiLsK54KJFAUcqCKCnsGUSXGGyDuhdZGVtjAVzTOih3F0roC5Z2Bh/o/YP/kBeS9oRttCQ==