The threshold check currently counts both trusted and untrusted signatures. Count only trusted signatures toward the threshold.
verifybinaries: fix trusted signature count #34889
pull dplusplus1024 wants to merge 1 commits into bitcoin:master from dplusplus1024:patch-3 changing 1 files +3 −3-
dplusplus1024 commented at 10:59 PM on March 21, 2026: contributor
-
6a2998939a
verifybinaries: fix trusted signature count
The threshold check currently counts both trusted and untrusted signatures. Count only trusted signatures toward the threshold.
-
DrahtBot commented at 10:59 PM on March 21, 2026: contributor
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
Reviews
See the guideline for information on the review process. A summary of reviews will appear here.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
- dplusplus1024 closed this on Mar 22, 2026
-
dplusplus1024 commented at 3:28 AM on March 22, 2026: contributor
Closing this after taking a closer look at the verifier semantics. The implementation and surrounding messaging make it look like the threshold is supposed to apply only to trusted signatures: signatures are split into trusted and untrusted buckets, related variables are named accordingly, and the code emits messages about trusted sigs meeting the threshold. On further review, I now assume the current behavior is intentional, with trust surfaced separately in the output for operator review and the threshold based on good signatures overall. The existing variable names, messaging, and control flow are internally inconsistent enough that the current implementation reads as a logical error.
-
fanquake commented at 5:50 AM on March 22, 2026: member
This is atleast the second time there has been confusion over this script, in as many months. So I think we probably need to do something here, to make the implementation less confusing.
Contributors