SetupConnection::check_flags for Protocol::MiningProtocol extracts the work-selection and version-rolling requirements as reversed >> 30 > 0 and reversed >> 29 > 0. After reverse_bits, those are true when any of the higher bits is set, so REQUIRES_STANDARD_JOB (bit 0) also reads as work selection and version rolling, and work selection also reads as version rolling. A downstream that advertises only standard jobs passes an upstream's work-selection or version-rolling gate.
The JobDeclaration branch of the same function uses the correct (reversed >> 31) & 1 form, and has_work_selection / has_version_rolling in the same file are correct. No in-tree role calls check_flags today, but it is public API.
Fix: drop reverse_bits and test flags & REQUIRES_WORK_SELECTION != 0 etc. directly, as the TODO in the JobDeclaration branch already suggests. Related: #2075 asks for a redesigned API.
SetupConnection::check_flagsforProtocol::MiningProtocolextracts the work-selection and version-rolling requirements asreversed >> 30 > 0andreversed >> 29 > 0. Afterreverse_bits, those are true when any of the higher bits is set, so REQUIRES_STANDARD_JOB (bit 0) also reads as work selection and version rolling, and work selection also reads as version rolling. A downstream that advertises only standard jobs passes an upstream's work-selection or version-rolling gate.The JobDeclaration branch of the same function uses the correct
(reversed >> 31) & 1form, andhas_work_selection/has_version_rollingin the same file are correct. No in-tree role callscheck_flagstoday, but it is public API.Fix: drop
reverse_bitsand testflags & REQUIRES_WORK_SELECTION != 0etc. directly, as the TODO in the JobDeclaration branch already suggests. Related: #2075 asks for a redesigned API.