Nodes on VPNs might rly struggle with disk space, as most of them have SSDs and SSD storage is not very cheap. Do you have noticed some nodes not being online anymore or is the network fine?
Below are the recommended system requirements based on our internal testing and scaling progress, made with bitcoind node software. Bitcoin SV will continue to scale on the road to, and beyond genesis. This will also mean these requirements should be expected to change as time goes on.
We have seen the above configuration in both mining and listener environments handle sequential 2GB block sizes and blocks with transaction counts exceeding 1 million transactions on the STN (using the additional recommendations below). This may vary as your individual demand scales up with your specific environment, application or use case.
If you are a Miner, it is also advisable you spend time ensuring your nodes have the highest possible connectivity with other miners.
With the increasing adoption of Bitcoin SV the transaction volume continues to rise. 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.
Whilst this is not how Bitcoin SV is intended to work, it is what we have to deal with for the short term while the SV Node teams focus on higher priority tasks which have a greater impact on scaling.
A solution is, to increase these following values from their defaults is to allow the node to remain efficient under high load situations. These situations include reorgs, which require the node to go back and reconsider transactions or blocks it has most probably already seen. A reorg can be the reason your node spikes from 1-2GB ram use to 3GB or more, if this is too much, your operating system may choose to end the process (stop bitcoind), or your node will crash with an “Out of Memory” error code.
Since reorgs and orphans are a part of the Bitcoin SV ecosystem and should be expected and not feared (more on this here) it would be wise to best prepare your environment for such situations. The default impaired settings and concepts inherited in bitcoind are too small for the volumes we see during operations on the STN or during a stress test on mainnet.
With this in mind, we suggest increasing a few default settings on your bitcoind node.
First of all, your mempool size allowance should be set to 10GB or more. This tells the node how much memory it should assign to storing unconfirmed transactions. This is done by adding the following to your bitcoin.conf file.
This restrictive memory limitation (300MB by default pre-genesis) is a consequence of the fee priority processing, inherited from BTC in order to maintain functioning tiny block sizes. In Bitcoin SV we don’t need this to be so little. The current overhead for storing transactions is in the realm of 5 times the real transaction size, for small transactions. This decreases dramatically for larger transactions. The SV Node team are actively working to remove all fee prioritisation code and hasten mempool processing to bring much-needed improvements to transaction propagation, acceptance and memory allocation. The net result will be a much faster and less memory extensive mempool.
In addition to increasing the mempool allowance, we also suggest increasing the signature and script cache. This tells the node how many accepted transactions in megabytes we can keep in our cache (RAM) improving performance by reducing expensive calls to recalculate signatures and scripts on the fly. We suggest setting these to 250MB or more to improve performance. This is done by adding the following to your bitcoin.conf file.
Please be aware that setting all three of the mentioned settings will add an additional memory requirement of 10.5GB on your node just for this aspect of bitcoind’s operation.
Lastly, we suggest adding maxorphantx to your bitcoin.conf as well. This value specifies how many orphan transactions can be kept in memory. This helps if your node is receiving a child transaction whose parent has not been confirmed in the blockchain. This means that the node will remember the child until it sees the parent or it exceeds its expiration time of 20 minutes. This is done by adding the following to your bitcoin.conf file.
The result of this, assuming 400byte average transaction sizes, is only a 4MB memory increase. If you have the ram/swap available, you can increase this number considerably (remembering transactions post genesis could be very large) avoiding any dropped orphans which may have parents your node has not seen yet.
https://bitcoinsv.io/documentation/miners/system-requirements
