Chinese 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.