A proof-of-work chain that pays for near misses, so nobody has to join a pool.
ACE is a fork of btcd. The network, database, script engine, mempool and headers-first sync are btcd's. What ACE changes is the proof of work and who gets paid for it.
Proof of work does not centralise because hash rate is unequal. It centralises because reward is lumpy.
A miner with one part in a million of a network finds a block roughly once every two years. Their expected income is perfectly fair; their realised income is nothing, in 96 % of months. Nobody runs a business on that, so they sell their hash rate to an operator who runs enough of it that the variance averages out — and that operator now decides which transactions their hash rate confirms. Pools, not whales, are the centralisation.
ACE removes the reason to pool instead of policing the result.
Miners publish fruits: proofs a few hundred times easier than a block, found by the same nonce search at no extra cost, hanging off a recent tip. Every block harvests all fresh fruits and pays 99 % of the subsidy per fruit at a fixed rate, plus four fifths of its transaction fees. This is precisely the object a mining pool already calls a share — ACE just pays for it on chain, so the miner never has to hand their hash rate to anybody.
Expected revenue is unchanged and still exactly proportional to hash rate, which is what keeps proof of work secure. Income variance falls by 496× on the subsidy, and by 79× even on a chain where fees are half of all revenue, which is what makes solo mining viable at 1/300th of the previous scale.
Two supporting rules close the escape hatches:
- ACEHash is memory-bandwidth-bound over a 2 GiB dataset, so the efficient frontier is a commodity GPU and an ASIC has to ship DRAM before it can compete.
- The puzzle is non-outsourceable: the predicate
d < targetcannot be evaluated without the payout secret, so an operator cannot have somebody else search on their behalf without handing over the ability to spend the reward.
Full argument, parameters, analysis and limitations:
doc/WHITEPAPER.md.
GPU compute request: doc/GRANT.md.
Reference implementation, pure Go, single core, AMD Ryzen 5 5625U. Reproduce with
go test -bench . ./acehash/ and go run ./cmd/acesim.
ACEHash attempt, 2 GiB dataset resident 5.85 µs
ACEHash attempt, recomputing every element 262.9 µs
memory-hardness margin 44.9x
income variance reduction, zero fees 496x (97% of the 513x ceiling)
income variance reduction, 10% fee revenue 373x (74x without fee smoothing)
income variance reduction, 50% fee revenue 79x (3.9x without fee smoothing)
smallest viable solo miner, Bitcoin 3.2e-04 (1 GPU among 3,162)
smallest viable solo miner, ACE <=1.0e-06 (1 GPU among >=1,000,000)
realised issuance over 200k blocks 100.3% (69.2% under a per-block cap)
new unspent outputs/yr, 10k miners 22.4M (269M if fruits paid at once)
And at production reward parameters on a real chain (F=512, 240-block payout
rota, 360 blocks — go test -tags soak -run TestACEMainnetScale ./blockchain/):
fruits harvested per block 510.6 (nominal F=512)
realised issuance 99.92% of schedule
rota conservation every credit paid exactly once
largest block 87,564 bytes
ProcessBlock 58 ms p50 (was 243 ms)
-> initial sync 8.4 hours per year of chain
Fruit proofs verify in parallel and the ancestor walk is memoised; per block that is now within ~1.4x of Bitcoin's. See whitepaper §8.9.
And on a real chain, from TestACEChainEndToEnd — three miners at 32:8:1 hash
rate, 24 blocks, through the production ProcessBlock path:
whale weight 3200 blocks 20 fruits 183 paid 79,976,871,523
farm weight 800 blocks 4 fruits 62 paid 25,910,628,316
solo weight 100 blocks 0 fruits 3 paid 1,462,500,000
The solo miner found zero blocks and was still paid. That row is the whole point.
Two real nodes, --simnet: a mining node produced eight blocks via the
generate RPC and a second node synced all eight over the peer-to-peer
protocol with zero rejections.
go build ./... # node, wallet tools, simulator
go test ./... # full suite
go test -tags rpctest ./integration/ # spawns real nodes over the p2p protocolThe integration suite is behind a build tag, as it is upstream: it compiles the
node, launches several of them, and binds fixed ports, which does not belong in
a routine go test ./.... Both commands pass. Four staged soft-fork activation
tests are skipped with a reason, because ACE activates CSV, segregated witness
and taproot at height 1 and so has no defined/started/locked-in/active
progression for them to walk through.
Go 1.25 or later. No cgo.
go run ./cmd/acesim # fairness simulation
go run ./cmd/acesim -json # machine-readable
go run ./cmd/acegenesis # re-mine the genesis blocks
go test -bench . ./acehash/ # proof-of-work benchmarksEverything ACE adds or changes:
acehash/ proof of work: dataset, search, verification
fruit/ fruit objects, merkle commitment, reward accounting
asert/ per-block difficulty from a fixed anchor
fruitpool/ unharvested fruits awaiting a block
blockchain/ace.go every consensus rule that differs from Bitcoin
mining/ace.go template assembly, payout table, two-for-one search
chaincfg/ace.go per-network ACE parameters
cmd/acesim/ fairness simulator
cmd/acegenesis/ genesis miner
doc/ whitepaper, grant request, benchmark records
Everything else is btcd, with two removals: signet, because a network whose blocks are signed by a trusted party is incoherent in a project about permissionless mining, and testnet4, because one testnet is enough.
| mainnet | |
|---|---|
| Block spacing | 60 s |
| Subsidy | 50 ACE, halving every 2,100,000 blocks (~4 years) |
| Supply | 210,000,000 ACE as a long-run mean, not a hard per-block cap |
| Base unit | 1 ACE = 100,000,000 chips |
| Proof of work | ACEHash, 2 GiB dataset, 32 lookups, epoch every 2048 blocks |
| Fruits per block | 512 rising to 1024 with difficulty, harvestable for 60 blocks |
| Reward split | 99.0 % fruits / 0.6 % harvest bonus / 0.4 % block |
| Fee split | 20 % block finder / 80 % fruits, remainder burned |
| Payout rota | fruit credits settle every 240 blocks (4 h), max 4096 payouts/block |
| Difficulty | ASERT, 2-hour half-life, anchored at genesis |
| Header | 182 bytes (80 + 102-byte solution) |
| P2P / RPC | 9911 / 9912 |
| Mining | --miningkey=<WIF>; ACE cannot mine to an address |
| Addresses | A… (P2PKH), C… (P2SH), ace1… (bech32) |
| Premine | none — the genesis coinbase creates zero coins |
Honest version, because a green badge that hides skips is worse than no badge.
ACE's own consensus rules are covered. TestACEChainEndToEnd mines a real
chain with three differently-sized miners and checks who got paid.
TestACEBlockRejectsTampering and TestGreedyCoinbaseIsRejected check that each
new rule actually rejects something. acehash, fruit, asert, chaincfg and
the ACE wire format each have full unit suites, including the non-outsourceability
property, the variance optimum, and the difficulty loop's response to a hash-rate
shock.
A number of inherited btcd tests are skipped, each with an explicit reason in
its t.Skip string. They fall into two groups: tests that replay captured
Bitcoin blocks (blk_0_to_4.dat.bz2, 277647.dat) or assert against hardcoded
Bitcoin addresses, keys and wire bytes — none of which can be valid under ACE
parameters; and fullblocktests, several hundred blocks hand-written against
Bitcoin consensus, whose port requires regenerating every one with a real ACEHash
solution. That port has not been done and the skips say so.
Ten defects were found by building, running and simulating rather than by
reading the design. Six were coding errors: a block's own proof could be
harvested as an explicit fruit and paid twice; testnet's difficulty floor made the
scaled fruit target overflow 256 bits; the daemon could not mine at all, because
nothing configured a mining key and the fruit pool was never drained after a
harvest; and every transaction identifier in a block received from a peer was
silently wrong, because btcutil sliced transactions out of the cached
serialisation at Bitcoin's 80-byte header offset.
That last one is instructive: locally built blocks take a different code path, so the unit tests, the end-to-end test and single-node mining all passed while peer-to-peer sync could never have worked. It was found by starting two nodes.
The fifth was found the same way: a reorg left the fruit pool holding fruits whose parent was no longer an ancestor, so the miner built a template, had it rejected, rebuilt it and had it rejected again, at full CPU, forever.
The other three were not errors — they were design rules that looked right and
were quantitatively wrong. A per-block issuance cap destroyed 31 % of all
issuance to the concavity of min(n, F), making the real supply ceiling 145 M
rather than 210 M. A constant fruit count gave the fairness claim an
undisclosed price ceiling, since payout cadence decayed in proportion to
adoption. And paying every fruit in the block that harvested it would have
created more unspent outputs in one year than Bitcoin has in its history. A tenth was not a code defect but a false claim: the whitepaper asserted that
hoarding your own fruits is "pure downside". Modelling strategic miners showed it
is worth up to +0.54 % of revenue and rises with hash-rate share, because
withholding a fruit captures the harvest bonus attached to it. The magnitude is
bounded by the harvest pot, which makes HarvestShareBP = 0.6 % load bearing
rather than incidental.
All ten are fixed — in the code where they were code, in the document where the document was wrong — and written up in whitepaper §6.1 with the figures that condemned them.
One further defect was in the test harness rather than the chain, and it matters
because it was hiding the state of the suite: rpctest's memory wallet was never
adapted to ACE — it watched an HD-derived address while coinbases pay
HarnessMiningKey, never registered that key with the node's transaction filter,
and signed legacy inputs where ACE pays pay-to-witness-public-key-hash. It was
therefore never funded, and seven integration tests failed for want of coins. An
earlier revision of this README implied the integration suite was green. It was
not.
Six independent reviews of the consensus code, with the serious findings verified
by running code: doc/AUDIT-FINDINGS.md.
It is not a third-party audit and does not claim to be. The headline is that a critical flaw was found and fixed — publishing two proofs leaked the miner's payout secret, because every proof from one search shared a one-time key and two of them solve for the key outright.
Every finding in that document is now closed except items that are cosmetic, unreachable, or deferred as policy decisions. Nothing open can halt the chain, forge a proof, steal a reward, or split two honest nodes. Coverage of the ACE consensus delta is 80–99 % per file, measured rather than asserted.
ACE is still not ready for a mainnet launch, for reasons that are now about
assurance rather than known defects: the GPU memory-hardness margin has never been
measured and is the design's central claim; the fullblocktests corpus is unported;
and there is no third-party audit and no independent implementation to cross-check
consensus against. The last two cannot be produced from inside the project.
Unlaunched. No live network, no seeders, no audit, no GPU kernel, no independent implementation to cross-check consensus against. The genesis blocks are mined and the chain runs end to end in tests. That is the current state and nothing more is claimed.
Read doc/WHITEPAPER.md §8 — the limitations section is
longer than this README's summary and it is the part worth reading first.
The upstream btcd README is preserved at
doc/UPSTREAM-README.md.
ISC, inherited from btcd. See LICENSE.