Mining on a Proof-of-Work network
A pool needs a client that follows the network's fork schedule and holds the chain tip under load. Mining is one of the capabilities the execution client carries, configured per deployment rather than assumed.
Share verification
Fukuii verifies each share before acknowledging it.
getWork and submitWork, with ECIP-1099 seedHash and DAG-epoch handling
Chain tip under load
Fukuii serves many miners from one node.
A mining-pool deployment profile (SNAP-serving on, tip-server sync) holds the chain tip under load
Snapshot distribution
Pools can seed state to other operators.
ERA1 frozen-segment bulk import + BitTorrent bootstrap distribution turns pools into snapshot seeders for the whole network
Deployment steps, configuration, and operator guidance for running Fukuii as a mining-pool node.
Mining-pool deployment guide →What the node does, and what the rigs do
Hashpower lives outside the node. Rigs and pools own it, and the node's job is to decide what should be hashed and to judge what comes back.
For each candidate block the node assembles the transaction set, computes the header the miners hash against, and hands out that header hash together with the seed hash for the current epoch and the difficulty boundary a solution has to meet. A miner that finds a nonce submits it back, and the node verifies the solution before acknowledging it rather than accepting it and discovering the problem later.
The chain tip moves while all this is happening. A template built on a block that has since been replaced is stale, and work submitted against it cannot be accepted no matter how good the solution is. That is why a pool tracks the tip closely, and why the node treats work older than a bounded threshold as expired instead of pretending it can still be used.
Enabling the miner
Mining is off by default. Turning it on needs two things: the miner itself, and a coinbase address for the blocks this node builds. A pool additionally needs the JSON-RPC surface reachable from wherever the pool process runs.
fukuii --network=etc \
--miner-enabled \
--miner-coinbase=0xYourPayoutAddress \
--rpc-http-enabled \
--rpc-http-port=8545 \
--rpc-http-api=ETH,NET,WEB3Proof-of-Work needs no consensus layer, so this is the whole deployment. Every configured Proof-of-Work network takes the same flags, with a different network argument.
The methods a pool calls
These are standard Ethereum JSON-RPC methods, so an existing pool does not need a Fukuii-specific integration. Shares are verified before they are acknowledged, which means a rejected share is rejected at submission rather than discovered later.
| Method | What the pool does with it |
|---|---|
| eth_getWork | Pulls the current header hash, seed hash and boundary for the block being built |
| eth_submitWork | Submits a nonce and mix digest; the node verifies before acknowledging |
| eth_coinbase | Reads back the configured payout address |
| eth_blockNumber | Tracks the chain tip to detect a stale template |
ECIP-1099 doubled the DAG epoch length on Ethereum Classic, from 30,000 blocks to 60,000. Epochs therefore advance half as often and the DAG grows at half the rate, which is what keeps it within reach of cards that would otherwise have been priced out of the network by memory alone. The seed hash a miner receives has to follow that schedule rather than Ethereum's, and the node handles it, so a pool reads the correct seed hash straight off eth_getWork with nothing to configure.
Why depth costs more than work
A Proof-of-Work chain is defended by the cost of out-computing it, and that cost is not a constant. Hashpower can be rented by the hour, so a network holding a minority of the hashrate available for its algorithm is, on accumulated work alone, reachable by anyone willing to rent enough of it briefly.
Ethereum Classic answers that by making depth expensive. Under ECIP-1100 a competing branch is not judged on accumulated work alone: the further back it forks from what the node has already accepted, the more work it has to carry before it will be adopted at all. A shallow reorganization behaves as it always did, while a deep one stops being something an attacker can rent for an afternoon. Fukuii implements the rule, so a node following the chain resolves branches the way the rest of the network does rather than on a weaker test of its own.
Difficulty carries its own history. The bomb that was designed to force a transition away from Proof-of-Work was delayed and then removed on Ethereum Classic, and a client validating the chain from genesis has to reproduce the difficulty each of those rules produced at the height where it applied. The node carries them as a ladder rather than a single setting, because the old blocks are still there and still have to come out right.
A network you have only just originated has no rigs pointed at it yet. For that case the node can seal its own blocks on the CPU, which is enough to move a development or test chain forward. It is not a production arrangement: on a live network the hashrate is the security, and a CPU is not it.
Standing up a network →