Blocks
Block Downloads Fail
Generally issues that effect block downloads (e.g. getblock) are the same as those effecting IBD (Initial Block Download). See Initial Block Download for more details.
Block Hex Dump fails
The RPC-function getblock
does not work for some big blocks. In some cases, getblock
returns an incorrect content and hex-dump size.
The workaround is to use the REST interface. See github.com/bitcoin-sv/bitcoin-sv/blob/master/doc/REST-interface.md.
Enable the REST interface by adding rest=1
in the config file, or -rest
on the command line.
Pruning Overview
The first time a node is run, it downloads all the blocks in the BSV blockchain (which starts with the original BTC Genesis block). The Initial Block Download (IBD) can be time consuming and take a number of days, however the process cannot be cut short. Downloading and validating the blocks (which includes validating the transactions in the blocks) is the proof that the blockchain on disk was built up from the Genesis block using PoW, and is an unadulterated copy of the BSV blockchain.
The node disk storage requirements can be reduced by enabling pruning via the -prune
configuration option. The node then attempts to keep storage below the specified value (in MB) by only keeping the newest blocks on disk. If manual pruning is enabled, the pruneblockchain RPC function can also be called to delete specific blocks.
The following points need to be considered:
The node will keep at least 6 blocks no matter what the pruning settings is.
Pruning is incompatible with configuration
-
txindex
=1
and-
rescan
.Reverting
-
txindex
=1
or-
rescan
will only take effect after restarting the node which in this case will repeat the whole IBD process from scratch.Pruning is disabled by default.
There is no recommended value for
prune
. Node operator should assume that blocks may exceed 4GB in size when choosing a value forprune.
The possible settings for pruning are:
If pruning is enabled,
getdata
andgetblock
RPC may fail as they may attempt to access a block that is no longer available. In that case, the error message looks like:
Arrival of New Blocks can make Node Unresponsive
The validation of a new arrived block is a high priority task since miners need to know if the new block is valid and whether they should continue to attempt to build on the current blockchain head or switch their resources to building on the new block. If the node mempools are in sync, then the node has already seen and validated the transactions in the new block and block validation can be very quick. If the node mempools are not in sync, which can happen if there is heavy traffic, the node will need to validate all the transactions it was not seen before. That can take some time (up to a minute). During that time the main SV node lock (cs_main) is held by block validation; without access to cs_main much of the other node functionality including the RPC interface is unavailable.
BCH and BTC Blocks
If a node connects to a non-BSV node, it may receive non-BSV blocks. That is not desirable but does not cause any fatal issues as the non-BSV blocks will not be successfully processed.
Diagnosis
Processing non-BSV blocks leaves characteristic messages in the log files. The following 'error' messages were the result of processing a BCH block on a BSV node.
and
To get information about connected nodes, type the following at the command line:
The node can be banned using the following command:
Prevention
SV nodes will refuse connections to non-BSV nodes based on the user agent in the version network message.
The banclieanua
config option can be used to further filter node connections based on the user agent . For example:
Last updated