Nakamoto Consensus powered by SHA256 Proof-of-Work
MiningMiningMining
eCash blocks are produced through a process called mining. Mining involves performing resource-intensive computations to produce Proof-of-Work, which powers eCash’s Nakamoto consensus system, similar to Bitcoin.
Mining is a specialized industry that uses purpose-built machines called mining rigs. These machines contain custom ASIC chips, and must be purchased specifically for crypto mining. Mining operations vary in scale from large industrial operations with full data-center warehouses with thousands of mining rigs, to hobbyists who run a small number of mining rigs at home.
Different cryptocurrencies may use different mining algorithms requiring different hardware. In the case of eCash, it uses the same SHA256 mining algorithm as Bitcoin, and thus BTC miners can also be used to mine eCash.
Once you have a mining rig set up, you have two options to start mining. You can point your hash power to a mining service provider, or you can set up infrastructure to mine on your own.
Using a mining service providerUsing a mining service providerUsing a mining service provider
Using a service provider has the advantage that it will handle technical setup for you, typically in exchange for a fee.
Solo mining with a service provider
One option is to “solo mine”, while outsourcing the block template contruction. This means the miner can point their hash power at a stratum endpoint, and they will receive the full miner portion of the block reward when their miners find a block.
Using a mining pool
Many mining services offer mining “pools”, which smooth out mining rewards to make payouts steadier and more predictable. There are several pools for mining eCash. Some options are listed here:
Running your own mining setupRunning your own mining setupRunning your own mining setup
Rather than relying on a service provider, a miner can take on the responsibility of handling their own technical setup. The advantage is that you retain privacy, and full control of the operation by not relying on a third party.
Solo mining
Solo mining requires running an eCash node along with specialized mining software. Such mining software is available here.
Operating a mining pool
Adding eCash to a mining pool can be an attractive option. Because eCash uses the same SHA256 mining algorithm as Bitcoin, the technical requirements are similar. One aspect to keep in mind, however, is that miners need to be aware of the avalanche consensus layer on eCash, to ensure that the blocks they produce will be accepted by the avalanche validators.
General recommendations
- The node generating the block template should have avalanche enabled (it is enabled by default).
- In order to maximize profit, a mining node can also be staking and benefit from the staking rewards.
- Ensure the node has good connectivity. It should accept inbound connections, accept both IPv4 and IPv6, and have no restriction in the number of connections (e.g. no
maxconnection
config set). - All the rules listed below are mandatory. If any is skipped your block will be rejected by the Avalanche consensus layer even though your node may succeed in submitting the block.
- If you need any help to add eCash support to your mining software, you can request for support in the eCash Development Telegram group.
Miner fund
The coinbase transaction must include a “miner fund” output. This portion of the coinbase is dedicated to funding the development of eCash.
"coinbasetxn": {
"minerfund": {
"addresses": [
"ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07"
],
"minimumvalue": 200000327
}
}
The miner fund output is a payment of at least “coinbasetxn.minerfund.minimumvalue” (in Satoshi) to the eCash address “coinbasetxn.minerfund.addresses[0]”. This amount should be subtracted from the total coinbase reward value.
Notes:
- This is a P2SH address
- The “addresses” field is an array for legacy reason, but all the value is expected to go to a single address and the array length is always 1.
- The address might change in the future and thus should not be hardcoded.
Staking rewards
The coinbase transaction must include a “staking reward” output. This portion of the coinbase is going to a staker who is contributing to the security of the eCash network.
"coinbasetxn": {
"stakingrewards": {
"payoutscript": {
"asm": "OP_DUP OP_HASH160 798038c8969512b74e82124a9a73641928932371 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914798038c8969512b74e82124a9a7364192893237188ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"ecash:qpucqwxgj6239d6wsgfy4xnnvsvj3yerwynur52mwp"
]
},
"minimumvalue": 62500102
}
}
The staking reward output is a payment of at least “coinbasetxn.stakingrewards.minimumvalue” (in Satoshi) to the payout script “coinbasetxn.stakingrewards.payoutscript.hex”. This amount should be subtracted from the total coinbase reward value.
Notes:
- The payout script can be any standard eCash script. You should not assume it is P2PKH or any other kind and use the script hex directly. The other fields are informational only and might be missing from the block template.
- The payout script is updated for each block and should not be hardcoded.
Heartbeat
The eCash network will enforce Real Time Targeting (also known as Heartbeat) starting with the November 15, 2024 network upgrade. This feature increases the difficulty when blocks are found at a faster rate than the expected 10 minutes average interval. The difficulty monotonically decreases over time until it reaches a plateau value. This is intended to avoid spikes in the difficulty that can lead to inconsistent block intervals.
Blocks with a hash that is higher than the Real Time Target will be rejected by the Avalanche consensus layer.
"rtt": {
"prevheadertime": [
1727793391,
1727790158,
1727785595,
1727781390
],
"prevbits": "1d00ffff",
"nodetime": 1727794761,
"nexttarget": "1b0c2b8b"
}
Your pool software need to make sure the submitted block hash complies with the Real Time Target. There are 2 options to achieve this:
- Read the real time target from the block template. The value is directly available in compact form in the field “rtt.nexttarget”. This field is updated at each call to “getblocktemplate”.
- Locally compute the target on the pool software. The formula is below:
uint32_t compute_next_target(gbt) { prevTarget = target_from_compact(gbt.rtt.prevbits); diffTime0 = max(1, now - gbt.rtt.prevheadertime[0]); target0 = prevTarget * 4.9192018423e-14 * (diffTime0 ** 5); diffTime1 = max(1, now - gbt.rtt.prevheadertime[1]); target1 = prevTarget * 4.8039080491e-17 * (diffTime1 ** 5); diffTime2 = max(1, now - gbt.rtt.prevheadertime[2]); target2 = prevTarget * 4.9192018423e-19 * (diffTime2 ** 5); diffTime3 = max(1, now - gbt.rtt.prevheadertime[3]); target3 = prevTarget * 4.6913164542e-20 * (diffTime3 ** 5); nextTarget = min(target0, target1, target2, target3); // The real time target is never higher (less difficult) than the normal // target. if (nextTarget < target_from_compact(gbt.bits)) { return target_to_compact(nextTarget); } return gbt.bits;
Notes:
- The Real Time Target does not impact the block header, in particular the difficulty bits should be the ones from the block template “bits” field.
- If your local time differs from the “rtt.nodetime” field, you can use this value to compensate or fix you system time.
- The node needs to accumulate 17 blocks before it is able to compute the Real Time Target (the “rtt.prevheadertime” array will contain 0 values otherwise). This could cause the node to mine at a lower difficulty during that time and get rejected blocks. In order to avoid this issue, you can add the option “persistrecentheaderstime=1” to your node configuration file. This instructs the node to save the reference times to disk and reload them on startup. This could cause a slight overshoot of the difficulty if a block is found while the node is restarting, but will ensure that no block will be rejected.
- If you are using the solo mining software from Bitcoin ABC, make sure to update with the latest master that supports the new feature.