[no description] https://upleb.uk/npub1q9geyrch3feyczz242sxjaa05yczv50dlpug082sjln2kl0wrnxst0nrfa/bitflash/atom?h=main 2026-09-05T05:08:30+00:00 2026-09-05T05:08:30+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-05T05:08:30+00:00 urn:sha1:66e0b9158d050c46b1ff2509faeee3f4573cac1c Brings the nine commits that are actually the latest on our lineage: isolated testnet parameters and genesis, optional 2 MB large pages for RandomX, and five README changes. This is what "up to date" means here -- not the 1.2.2x tags, which carry higher version numbers but were cut 2026-07-30, three weeks before the line we ship, and which upstream/main does not contain. Three conflicts, all resolved toward upstream's structure while keeping what this fork knows: main.cpp -- upstream moved genesis construction into BuildGenesisBlock() so mainnet and the new testnet can share it. Verified byte-for-byte before taking it: MAINNET_GENESIS_TIMESTAMP, _TIME (1753315200), _NONCE (3141), _HASH, _MERKLE, the scriptPubKey, nBits and nVersion all equal what this tree built inline. The mainnet genesis hash is unchanged and the asserts still guard it. Kept our warning about never editing those inputs, and kept our note that 1753315200 is 2025-07-24, not 2026 -- upstream's comment on that constant states the wrong year. net.h -- DEFAULT_PORT = htons(8433) becomes MAINNET_PORT/TESTNET_PORT in host order. Nothing is lost: net.cpp's GetDefaultPort() applies htons() itself and is what every caller uses, so the value reaching a sockaddr is unchanged and mainnet stays on 8433. selftest.cpp -- the known-tests string had diverged in both directions. Took the union: upstream's network-params alongside our payout-ledger, rather than dropping either. Gates: 15/15 selftests (our 14 plus upstream's network-params), consensus constants unchanged against e4f898c except the pre-existing MAX_BLOCK_SIZE_GEN, mainnet genesis intact, compactblock's 17 checks still pass, money-log check ok, GNU_STACK RW. 2026-09-03T22:33:20+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T22:33:20+00:00 urn:sha1:b810d86752ddb2674118f737582c924bb9eb74c1 # Conflicts: # Makefile 2026-09-03T21:49:35+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:35+00:00 urn:sha1:db44eac5d347c229539946e8d61f1ff0d1f68001 2026-09-03T21:49:35+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:35+00:00 urn:sha1:ea8fe94658bf20d2b669b619231238f12e6bd8fc 2026-09-03T21:49:35+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:35+00:00 urn:sha1:944f93f163cb560f095556834b6eb75bfde60c9c 2026-09-03T21:49:35+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:35+00:00 urn:sha1:424da766b76ba572cc9a93c4dd03736dace04d80 2026-09-03T21:49:35+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:35+00:00 urn:sha1:3c18a66ef601d90f08ea622021cb02bafab1601b 2026-09-03T21:49:26+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-03T21:49:26+00:00 urn:sha1:c8f11a375af6fee608182e93d8b048da41718ebb 2026-09-02T17:51:07+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-02T17:51:07+00:00 urn:sha1:04f5b6827c9bc1d2b225318db0c3f0d1e27e6819 2a804c2 resolves a job's prevhash against mapBlockIndex under cs_main so the worker log names the chain the pool is building on (#15). It did that on every mining.notify, unconditionally, before the LogPrint that consumes the answer -- and LogPrint's category gate and its 3-second dedup both run after the lookup has already happened. The dedup bounds the log line. It never bounded the work. That left an unbounded cs_main acquisition rate on the participant's socket-reading thread, driven by the remote pool. Block validation can hold cs_main for a long time, and this thread is the one that handles mining.set_difficulty and share-submission replies, so a pool sending rapid notifies could stall the responses a miner is paid for. Hashing was never at risk -- jobShared is published before the lookup -- but the reader is not free to block. Most notifies in a round are a new job on the same tip, so the answer is now cached and re-resolved only when it could come out differently: a prevhash we have not resolved, or one we could not resolve last time while the chain has since moved. A block's height is fixed once mapBlockIndex knows it, so a cached "known" cannot go stale; an unknown is re-checked whenever nBestHeight changes, which is what catches a pool we were behind once we have caught up. The worst case -- a different prevhash every notify -- degrades to exactly the old cost, never worse. Measured over a 10-tip round of 30 jobs each, 300 acquisitions become 10; over 1000 notifies on a single fork we do not have, 1000 become 1. The log line is unchanged and still prints in full for every job, cached or not: prevhash plus height-or-"unknown to our chain". Nothing #15 asked for is lost, and a fork we cannot resolve keeps saying so on every job. The lookup is also wrapped in LogAcceptsCategory("worker") so the work follows the gate deciding whether anyone reads it. That is a no-op today -- "worker" is default-on in LogCategoryDefaultOn() -- and is there so the coupling survives the category ever moving behind -debug. The caching, not the gate, is what removes the acquisitions. The cache is four locals in the session scope, not statics: participant mode runs exactly one such thread (StartMinerThreads forces nThreads to 1 for MINE_PARTICIPANT), and session scope additionally means a reconnect re-resolves rather than trusting an answer from before a possible change of pool. 2026-09-02T17:13:06+00:00 bitflash-maintainer noreply@bitflash.invalid 2026-09-02T17:13:06+00:00 urn:sha1:ca03f8e9416837acfac825f02a6c592e07e0c4df PoolParticipantMiner returned true from its normal cleanup path whether or not the pool had ever sent work, so a pool that completed the tunnel and then dropped was indistinguishable from a healthy one. The caller reset nRetrySecs to 10 on every such "session", pinning the reconnect at a flat 10s and defeating the backoff in precisely the case it was added for. It cleared nFailingSince as well, so the "failing for N minutes" line never printed either -- the worker went back to idling silently. Return true only once at least one well-formed mining.notify has arrived. The existing early returns are unaffected: they already mean "no session", which stays the right answer for any path that leaves the worker without work, a failed hash-thread spawn included.