Bitcoin's monetary rules. BC3's own hardware class.
BitcoinIII
A Bitcoin relaunch with BC3Hash proof-of-work and no inherited ASIC ceiling on network security.
BC3Hash + aserti9-2d activated at block 64,360. Mining software and nodes must support the new rules.
Bitcoin's monetary design, with a proof-of-work algorithm in a hardware class of its own and difficulty adjustment built for today's mining economy. No inherited ASIC fleet. No larger chain setting the ceiling on BC3's security.
The security of a proof-of-work (PoW) network depends on an attacker not being able to independently amass more hashrate than the network as a whole. For an ASIC-mineable coin, it matters not just how much mining hardware exists, but how much of that hardware is securing the coin itself rather than a larger neighbour.
Bitcoin went live in January 2009. It began with CPUs, then moved to GPUs, FPGAs and, finally, ASICs. Those application-specific integrated circuits were developed for Bitcoin and grew with Bitcoin: dedicated chips computing SHA-256d over its block headers. Bitcoin became the dominant network in that hardware class. Rewriting its history requires competing with the enormous fleet already securing it, which makes deeply confirmed transactions extraordinarily expensive to reverse.
A smaller coin that adopts SHA-256d inherits the opposite problem. It competes with Bitcoin for the same hardware in perpetuity, unless it overtakes Bitcoin in that hardware class. A fraction of an existing fleet can be much larger than the smaller network's entire hashrate. The same exposure arises whenever a new coin shares its mining algorithm with a much larger incumbent.
Shared hardware creates an inherited security ceiling. A network whose history can be rewritten by hardware primarily used elsewhere has a fundamental obstacle to attracting lasting trust and meaningful capital. BC3 exists to remove that obstacle, rather than accept it as permanent.
BC3 addresses the hardware-class problem at its source: the proof-of-work algorithm. Its first fork, at block 30,240, replaced SHA-256d with SHA3-256t — three nested SHA3-256 hashes of the standard 80-byte Bitcoin block header, with a little-endian PoW comparison.
That was not enough separation. Tari's SHA3x uses the same triple SHA3-256 core, despite different input data and nonce format, and a big-endian interpretation of the final digest for its PoW difficulty calculation. Those are different PoW definitions, but the central hashing workload is too similar to provide the hardware isolation BC3 requires. A difference in header format or byte order is not the foundation on which BC3 intends to build its long-term security.
The fork at block 64,360 therefore replaced SHA3-256t with BC3Hash. Rather than another arrangement of familiar hashing rounds, BC3Hash combines standard cryptographic hashes with a substantial, purpose-built mathematical workload. Existing SHA-256d and SHA3x mining datapaths cannot execute that workload merely by changing firmware, nonce handling or digest comparison.
Total hardware isolation from existing mining ASICs. Not ASIC resistance.
Dedicated BC3Hash mining needs a new BC3-specific ASIC design and newly fabricated silicon. It is not a cheap modification of a miner built for another coin. The goal is for BC3's ASIC fleet to be built for BC3 and to grow with BC3.
CPUs and GPUs are programmable and can mine BC3 with suitable software; they are not the fixed-function ASICs this isolation concerns. A young network still needs real hashrate and real economic support. BC3 removes the inherited ASIC ceiling, not the need to build a strong network.
Technical reference: Tari's SHA3x implementation. BC3's historical and current hash rules are documented in the Core fork specification.
BC3Mix and BC3Hash have different jobs. BC3Mix is the custom mathematical mixing component. BC3Hash is the complete, 256-bit cryptographic hash used to identify blocks and check proof of work.
BC3Mix: the BC3-specific workload
BC3Mix brings together 64-, 128- and 256-bit arithmetic, modular multiplication and exponentiation, modular inversion, bitwise mixing and repeated scalar multiplication on the secp256k1 elliptic curve. These interconnected operations make the workload fundamentally different from existing fixed-function mining algorithms.
In the block-hashing path, BC3Mix takes a domain-separated, 512-bit SHA3-512
digest of the header and produces a 256-bit mixing result. The
512 in BC3Mix512 describes that fixed-size input,
not the output length. BC3Mix is a component, not the entire block hash.
BC3Hash: standard cryptography around the mixer
BC3Hash also hashes the original header independently with SHA3-384, SHA-512, RIPEMD-160, BLAKE2s-256 and BLAKE2b-512. It concatenates those fixed-length results with the BC3Mix result and applies a final, domain-separated SHA3-256. The standard-hash branches do not depend on BC3Mix's output.
BC3Mix is never the cryptographic security bottleneck. Even a critical weakness in BC3Mix would not, by itself, break BC3Hash: the original input remains committed through independent standard-hash branches and the final SHA3-256. Under the usual security assumptions for those standard primitives, BC3Hash retains its cryptographic protection rather than resting on the strength of the custom mixer alone.
This is a separation of responsibilities: BC3Mix supplies the distinctive mathematical workload; standard cryptographic hashes anchor the full construction's security. A shortcut in BC3Mix could still change the cost of mining. That is different from finding collisions or preimages in BC3Hash. Here, “bottleneck” means cryptographic security, not running time: BC3Mix is deliberately computationally expensive.
See the exact BC3Hash construction
Let h be the 80-byte block header and D the ASCII
string BC3Hash-BlockHash-Algorithm/BitcoinIII-PoW/2026.
|| means byte concatenation, without a terminator.
s384 = SHA3-384(D || "/SHA3-384" || h)
s512 = SHA3-512(D || "/SHA3-512" || h)
mix = BC3Mix512(s512)
sha = SHA-512(D || "/SHA-512" || h)
r160 = RIPEMD-160(D || "/RIPEMD-160" || h)
bs = BLAKE2s-256(D || "/BLAKE2s" || h, person_s)
bb = BLAKE2b-512(D || "/BLAKE2b" || h, person_b)
hash = SHA3-256(D || "/SHA3-256" || s384 || mix || sha || r160 || bs || bb)
person_s = 0a20e811610908ba
person_b = 1e80f2fddc5818d6fe9b581e3bd4930bThe BLAKE2 personalization values above are decoded hex bytes. BitcoinIII interprets the raw final digest as a little-endian integer for the PoW target check; displayed block IDs reverse the raw digest bytes.
Source: BC3Hash implementation, BC3Mix implementation and Python reference.
At the same fork, BC3 replaced the old 2,016-block difficulty retarget with aserti9-2d, which adjusts the target for every block. This was not just a precision upgrade. Changing the difficulty-adjustment algorithm (DAA) was necessary to make BC3's mining rules fit the economy in which it must grow.
The mining economy has changed
Bitcoin's monetary foundations are the blueprint; its starting conditions cannot be recreated. A new coin launched in 2026 cannot expect to follow Bitcoin's path to growth simply by copying every mining-related consensus rule. The DAA, like the proof-of-work algorithm, is one of the rules that must reflect a different world.
General-purpose compute now has many more places to go than during Bitcoin's CPU-, GPU- and FPGA-mining years. GPU owners can train or run AI models, rent out their hardware, or mine whichever compatible cryptocurrency offers the best return. That compute is not committed to one chain: miners can stop hashing for BC3 almost immediately when a more attractive opportunity appears elsewhere.
Why 2,016 blocks is too long to wait
An epoch-based DAA leaves a young chain exposed to opportunistic hashrate. A large influx can accelerate blocks and drive up difficulty at a retarget, then disappear while that difficulty remains in force. The miners who stay are left doing work calibrated to a fleet that is no longer there, with slow blocks and delayed confirmations until the next retarget boundary.
That boundary is measured in blocks, not calendar time. The remaining blocks must still be mined before difficulty can adjust. A nominal two-week epoch can therefore stretch far beyond two weeks after a large hash exit. Waiting for a 2,016-block boundary is not a practical response to compute that can leave in seconds.
Hardware isolation and responsive difficulty solve different parts of the same problem.
BC3Hash gives BC3 an independent mining-hardware class. Per-block ASERT lets difficulty respond as blocks arrive, instead of holding it fixed until the next epoch boundary. For a new coin growing in today's mobile compute market, per-block adjustment is the realistic and practical choice.
Per-block does not mean instantaneous: ASERT uses the timestamps of mined blocks, so the first block after a sudden hash exit still has to be found at its already-determined difficulty. Its two-day half-life governs the response. It removes the epoch-boundary wait, not the need for miners or the possibility of individual slow blocks.
The destination: king of its own hardware class
If and when BC3-specific ASICs are developed, the economics change. A dedicated BC3Hash datapath cannot simply be redirected to AI training or an unrelated proof-of-work algorithm. Its economic purpose is mining BC3, rather than moving between the many uses open to a general-purpose GPU. The goal is for BC3 to become king of its own hardware class, just as Bitcoin became the dominant economic home for its dedicated mining hardware. ASERT makes the path towards that BC3-specific hardware economy more resilient; BC3 does not have to wait for ASICs before addressing volatile hashrate.
Background: Bitcoin's epoch-based retarget, ASERT's rationale and specification and GPU rental-market documentation.
A proven formula. More precision.
BC3's aserti9-2d uses the same tried-and-tested underlying ASERT exponential formula as Bitcoin Cash's aserti3-2d, with the same two-day half-life and a ten-minute target block interval.
ASERT compares elapsed time with an absolute block schedule. When blocks arrive ahead of schedule, difficulty rises; when they fall behind, difficulty falls. A schedule error of two days corresponds to a factor of two in the ideal target, before the PoW limit is applied.
The improvement is in how the fractional exponential is calculated:
f(x) = 2x,
x ∈ [0, 1].
BCH's aserti3-2d uses a cubic approximation and 16 fractional
bits. BC3's aserti9-2d uses a
9th-degree polynomial and 31-bit fractional arithmetic,
approximating the same function far more accurately.
aserti3-2d
Degree 3 · 16 fractional bits
Bitcoin Cash's ASERT implementation
aserti9-2d
Degree 9 · 31 fractional bits
BitcoinIII's higher-precision implementation
The fractional grid is 32,768 times finer. All consensus
arithmetic is integer-only, with fixed coefficients and explicit rounding
rules, so nodes agree exactly. This improves the approximation, not the
ten-minute target or the underlying controller; final targets are still
encoded in Bitcoin's compact nBits format.
Anchor, formula and consensus arithmetic
The activation block, F = 64360, has the fixed target
nBits = 0x1c0ffff0 (difficulty 16). For a later candidate,
height_diff is its parent's height minus F, and
elapsed is its parent's timestamp minus the timestamp of
block F - 1 on that branch.
T_next = T_anchor * 2^((elapsed - 600 * (height_diff + 1)) / 172800)The implementation approximates the fractional power in Q31 arithmetic,
evaluates the degree-9 polynomial with rounding at each Horner step, and
clamps the result to the permitted target range before compact encoding.
The first ASERT adjustment is at F + 1; the old epoch
boundaries no longer trigger retargets.
References: BC3 aserti9-2d specification and BCH aserti3-2d specification.
BC3 began as a fork of BitcoinII, itself a Bitcoin relaunch. The current BitcoinIII-Core v31.1.3 codebase is based on Bitcoin Core v31.1. BC3 preserves Bitcoin's monetary rules: a maximum supply of 21 million, a ten-minute target block interval and halvings every 210,000 blocks. Its current consensus changes include both BC3Hash proof of work and aserti9-2d difficulty adjustment.
- Before block 30,240
SHA-256d
The original Bitcoin-style proof of work and 2,016-block difficulty retarget.
- Block 30,240
SHA3-256t
The first PoW fork switched to triple SHA3-256. Difficulty reset to 1 (
0x1d00ffff); the 2,016-block retarget remained. - Block 64,360 · Current rules
BC3Hash + aserti9-2d
The second fork established the new hash and per-block ASERT. The activation block used difficulty 16 (
0x1c0ffff0); ASERT applies from the next block onward.
Hash selection remains an intrinsic property of the 80-byte header. Version bit 12 selects the historical SHA3-256t algorithm when bit 11 is clear. From block 64,360, version bit 11 must be set and selects BC3Hash; bit 12 may have either value. The selector bits remain part of the hashed header.
Source: mainnet parameters and header and activation rules.
BC3 is mineable with CPUs and supported GPUs using BC3Hash software. Old SHA3-256t miners must be replaced or upgraded: they do not produce valid proof of work under the current rules. General-purpose hardware can be reprogrammed; a fixed-function mining ASIC cannot be turned into a BC3Hash chip by changing a pool address or firmware.
A different hash. A different scale.
BC3Hash performs substantially more mathematical work per hash. As a practical rule of thumb, it is approximately 1,000 times slower than SHA3-256t on comparable general-purpose mining hardware. A pre-fork rate of 1 TH/s therefore corresponds to roughly 1 GH/s after the fork, at that approximate ratio.
This is an approximate workload comparison, not a fixed conversion rule between algorithms. The ratio depends on the hardware and implementation; it does not mean that SHA3-256t ASICs can be converted into BC3Hash miners. Raw hashrate numbers from different PoW algorithms are not directly comparable.
Bitcoin mining ASICs
A SHA-256d datapath cannot execute BC3Hash's modular arithmetic, elliptic-curve workload and complete hash construction.
SHA3x mining ASICs
The shared triple-SHA3 core that motivated the fork is gone. BC3Hash requires a new BC3-specific silicon design.
CPUs
General-purpose CPUs can execute BC3Hash with suitable software. Expected results depend on the processor, implementation and network difficulty.
Supported GPUs
GPUs can run BC3Hash-specific mining software. Use a miner and pool that explicitly support BC3Hash, not just the old BC3 algorithm.
Start with the current BitcoinIII-Core release and consult the BC3 community for compatible miners and pools. Core downloads are node and wallet software, not standalone GPU-miner packages.
Technical specifications.
- Ticker
- BC3
- Maximum Supply
- 21,000,000 BC3
- Current Release
- BitcoinIII-Core v31.1.3
- Upstream Codebase
- Bitcoin Core v31.1
- Block Hash / PoW
- BC3Hash · 256-bit output
- Proof-of-Work Input
- 80-byte block header
- PoW Comparison
- Little-endian integer
- Block Time
- 10 minutes (target)
- Difficulty Adjustment
- aserti9-2d · every block
- ASERT Half-Life
- 2 days · 172,800 seconds
- ASERT Approximation
- Degree 9 · 31 fractional bits
- Halving Interval
- 210,000 blocks
- First PoW Fork
- 30,240 → SHA3-256t
- Latest Fork
- 64,360 → BC3Hash + ASERT
- Current Algorithm Signal
- Version bit 11 required; bit 12 optional
- BC3Hash Activation nBits
- 0x1c0ffff0 (difficulty 16)
- Mainnet P2P / RPC
- 38338 / 38337
- Address Formats
- P2PKH, P2SH, P2WPKH, P2WSH, P2TR
- Default OP_RETURN Policy
- One output; 83-byte script limit (relay policy, not consensus)
- Release Verification
- Detached OpenPGP signatures
The versioned BitcoinIII-Core v31.1.3 source defines the consensus parameters and default relay policy.