diff options
| author | bitflash-maintainer <noreply@bitflash.invalid> | 2026-09-02 05:42:17 +0000 |
|---|---|---|
| committer | bitflash-maintainer <noreply@bitflash.invalid> | 2026-09-02 05:42:17 +0000 |
| commit | d7b1e8a1d54192df2fcf633fbcdffb43389ff8e2 (patch) | |
| tree | c65b2390f4fef2d99c09579e7544387a65cf4f69 /src/btfrv.h | |
| parent | e4f898c4a6b9900553c64b9804889b5fdae3e55f (diff) | |
pool: guard the share-target floor where the old cap branch was dead
ShareTargetFromDifficulty ended with
if (t < diff1 && difficulty < 1.0) t = ~uint256(0);
which can never fire: t = diff1/difficulty, so difficulty < 1.0 implies
t > diff1 and the two conditions exclude each other. The branch was
reaching for a real hazard, though, so say the hazard directly instead
of deleting the guard: diff1 is ~uint256(0) >> 12, a hair under 2^244,
so the true share target stops fitting in a uint256 once difficulty
reaches 2^-12 (1/4096), and the fixed-point divisor
(uint64)(difficulty * 65536.0) truncates to zero -- a division by zero
-- for any difficulty under 2^-16. Past the first threshold
getuint256() would return the low 256 bits of an oversized quotient, a
wrapped target that is arbitrarily HARDER than difficulty 1. Both
thresholds sit far below VARDIFF_MIN (0.001), so nothing live comes
near this; the guard exists for any caller that bypasses vardiff. At
those difficulties every hash is meant to be a share, so return
all-ones, the easiest representable target. Boundary verified
numerically against the exact fixed-point algorithm: at difficulty
exactly 1/4096 the quotient is 2^256 - 4096 (fits), one ulp below it
overflows, and below 2^-16 the divisor is zero.
Closes #11
Diffstat (limited to 'src/btfrv.h')
0 files changed, 0 insertions, 0 deletions