BitcoinIII

Since the advent of rental hashrate, the bar to attacking different networks has been significantly lowered. Anybody with adequate funds can log into their MiningRigRentals, NiceHash, or Braiins Hashpower account, deposit funds, rent hashrate for a plethora of different PoW algorithms, and point it at the chain of their choosing.

Attacking a coin no longer requires any investment in hardware. It only requires the attacker to have sufficient funds to cover the rental cost for the time required. Any new coin whose proof-of-work algorithm has a large pool of rental hashrate available — or that shares its algorithm with a much larger coin — is at the mercy of anybody with the will and funds to attack it.

BC3 mitigates the rental-hashrate problem by changing the only aspect of consensus required: the block hash/proof-of-work algorithm. All other consensus rules remain identical to Bitcoin. There is no SHA3-256t rental hashrate market: an attacker cannot simply log into an existing rental-hashrate platform, rent a large amount of compatible hashpower, and point it at BC3.

This does not make BC3 immune to attack. In its infancy, BC3 remains vulnerable in the same way any new proof-of-work network is vulnerable: a determined attacker with enough independently assembled compute could still overwhelm the honest network. That is a very different proposition, however, from renting ready-made, algorithm-compatible hashrate and redirecting it at short notice.

The goal is to force any serious attacker to do the harder thing: assemble, configure, coordinate, and sustain the required compute themselves, rather than buying temporary access to an existing hashrate market. As BC3's own network hashrate grows, that burden should rise quickly. The security argument is not that BC3 is impossible to attack from day one, but that it avoids the most dangerous weakness faced by coins whose proof-of-work can already be rented at scale.

BC3 is a fork of the BitcoinII (BC2) Core v29.1 codebase, which itself is a fork of Bitcoin Core v29.1. The code is identical to Bitcoin, except for network-specific parameters and a single consensus change: the block hash and proof-of-work algorithm is SHA3-256t — three iterations of SHA3-256 — instead of SHA-256d.

The block hash algorithm is determined via version bit 12. Pre-fork blocks do not have bit 12 set; and post-fork blocks must. This keeps the block hash algorithm an intrinsic property of the block header itself, and leaves the BIP320-reserved ASIC rolling bits and the top three BIP9 bits untouched. Additionally, this approach still allows the lower 12 version bits to be used for BIP9 signalling.

The hard fork activated at block height 30,240. Block 30,239 was the last SHA-256d block; block 30,240 was the first SHA3-256t block. The difficulty was reset to 1 (nBits = 0x1d00ffff) at the fork height to give the new network room to find its hashrate without producing blocks 35 years apart.

BC3 is mineable by anyone with a CPU or GPU. There is no rental market for the algorithm, and there is no compatible ASIC inventory sitting in datacenters waiting to be repointed. Unlike coins that share a proof-of-work algorithm with a much larger network, BC3 does not inherit a vast pool of external hashrate that can be redirected at short notice. Every hash pointed at BC3 today comes from someone who deliberately chose to mine BC3 with their own hardware.

GPU mining software appeared within hours of the fork. This is the reality of launching a coin in 2026, not 2009: SHA3-256 is a NIST standard with optimised implementations everywhere, and the codebase is open. Thus, BC3 does not promise an extended CPU-only phase. Its claim is narrower and stronger: the chain is not exposed at birth to an existing market of compatible rental hashpower or to idle ASIC fleets built for a larger neighbour.