Node Setup
Instructions
Running a mining node, you can earn block reward and transaction fees each time
you add a new block of transactions to the blockchain.
Complete package installation
A mining node is a program that fully validates transactions and blocks by building on the chain tip. Mining nodes help the network by accepting transactions and blocks from other mining nodes. They validate those transactions and blocks, and relay them to further mining nodes.
System requirements
   
Development
To only follow the most Proof of Work (PoW) chain and handle small volumes of other tasks (RPC requests as an example)
ProductionMinimum
To handle a medium volume of workload while maintaining real time sync with the current chain tip
ProductionRecommended
To handle high volume of work or has txindex enabled, or a mining operation.
Processor 4 Core, 8 thread CPU 8 Core, 16 thread CPU 8 Core, 16 thread CPU
10 core 20 thread CPU or more preferred
RAM 6GB of Ram + 10GB Swap 64GB Ram + 64GB Swap 64GB Ram + 64GB Swap
Internet 10+ Mbit (up and down) 100Mbit+ (up and down) 1Gbit+ (up and down)
Node Configuration

The Genesis Upgrade removes the default setting for the maximum block size and defines this as a “mandatory consensus parameter”. The upgrade also defines a new setting, the maximum script memory usage mandatory consensus parameter. The values for these parameters must be manually configured in the software by the system administrator. This page provides information on these parameters and recommendations on how to choose the values of these parameters.

A summary of the recommended method of choosing these parameters is to survey the major Bitcoin SV miners and choose the same, or larger, parameters. It is expected that miners will begin to publish these settings in their MinerID coinbase documents in the near future. However in the meantime we will regularly update this page with known settings of various miners manually.

Mandatory Settings

Based on the current known miners settings, the following would be deemed safe:

Safe values
Maximum block size
Maximum script memory usage
Miner
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
Listener
excessiveblocksize=2000000000
maxstackmemoryusageconsensus=200000000
Currently known values
Maximum block size
Maximum script memory usage
CoinGeek
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
Mempool
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
SVPool
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
Taal
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
NourPool
excessiveblocksize=1000000000
maxstackmemoryusageconsensus=100000000
Optional settings

With the increasing adoption of Bitcoin SV the transaction volume continues to rise. Along with the explosive use of data transactions (op_returns) it is possible your Bitcoin SV node will not be able to handle the volume of traffic reaching your mempool or be inundated with computationally heavy requests.

As a result, the node will drop transactions to allow higher fee paying ones in, increasing computation at a later point, or worse, cease to function.

A solution is to increase values of the 3 following settings from their defaults. This will allow the node to remain efficient under high load situations.

Default values
Mempool size allowance
Signature and script cache
Maxorphantx
PreGenesis
maxmempool=300
maxsigcachesize=TBC
                maxscriptcachesize=TBC
maxorphantx=TBC
PostGenesis
maxmempool=8000
maxsigcachesize=TBC
                maxscriptcachesize=TBC
maxorphantx=TBC
Frequently Asked Questions

All the settings can be done by either adding parameters or changing their values in your bitcoin.conf file.

The capacity of the Bitcoin SV network is determined by the miners that confirm blocks. Miners will analyse the state of the blockchain, the capability of the software, and other factors and determine values for the mandatory consensus parameters. Miners will publish the values that have been chosen.

The recommended method for determining the values of the mandatory consensus parameters is to survey the values that have been published by miners, taking account of the capabilities of the miner, and to use similar values if you are mining or higher values if you are not.

Note that miners may change the values that they use so a regular review of the settings is recommended.

We define a node as an instance of Bitcoin SV that building blocks for the purpose of mining. A Blockchain listener is an instance of Bitcoin SV that is not involved in the mining process.

For a listener we recommend choosing settings at least twice as high as that of the miners. This is in order to give some room so that when miners increase their settings in the future you are unlikely to be forked from the network by having a setting lower than theirs.

If your setting is lower than the majority of miners and a block is mined that exceeds your settings then your Bitcoin SV instance will reject that block and all future blocks mined on top of it, effectively forking off the network. However if you are not mining it is likely that your fork will not be extended and your instance simply ceases following the longest chain. In this case the remedy is simply to increase the values of those settings and restart your Bitcoin SV instance. It will then accept the failed blocks and catch up to the rest of the network.

It is possible to set either of these parameters to effectively unlimited by choosing a value of “0”. If this option is chosen there is no risk of forking off the network. However in the event of an extremely large block being mined it is possible your node could run out of memory and crash. If you have followed best practices and allocated a large swap file and have minimum recommended memory this is only likely in an attack scenario. If this happens the remedy is to set your limits similarly to the majority of miners and restart the node.