Blockchain Settings

The following blockchain settings are implemented in the libbitcoin-blockchain and exposed in both Bitcoin Node (BN) and Bitcoin Server (BS).

[blockchain]
# The number of cores dedicated to block validation, defaults to 0 (physical cores).
cores = 0
# Use high thread priority for block validation, defaults to true.
priority = true
# Use libconsensus for script validation if integrated, defaults to false.
use_libconsensus = false
# The maximum reorganization depth, defaults to 256 (0 for unlimited).
reorganization_limit = 256
# The block version for block creation and transaction pool validation, defaults to 4.
block_version = 4
# A hash:height checkpoint, multiple entries allowed, defaults shown.
checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
checkpoint = 0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d:11111
checkpoint = 000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6:33333
checkpoint = 00000000001e1b4903550a0b96e9a9405c8a95f387162e4944e8d9fbe501cd6a:68555
checkpoint = 00000000006a49b14bcf27462068f1264c961f11fa2e0eddd2be0791e1d4124a:70567
checkpoint = 0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20:74000
checkpoint = 00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97:105000
checkpoint = 000000000000774a7f8a7a12dc906ddb9e17e75d684f15e00f8767f9e8f36553:118000
checkpoint = 00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe:134444
checkpoint = 000000000000033b512028abb90e1626d8b346fd0ed598ac0a3c371138dce2bd:140700
checkpoint = 000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763:168000
checkpoint = 000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317:193000
checkpoint = 000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e:210000
checkpoint = 00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e:216116
checkpoint = 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932:225430
checkpoint = 000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214:250000
checkpoint = 0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40:279000
checkpoint = 00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983:295000
# Testnet checkpoints.
#checkpoint = 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943:0
#checkpoint = 00000000009e2958c15ff9290d571bf9459e93b19765c6801ddeccadbb160a1e:100000
#checkpoint = 0000000000287bffd321963ef05feab753ebe274e1d78b2fd4e2bfe9ad3aa6f2:200000
#checkpoint = 000000000000226f7618566e70a2b5e020e29579b46743f05348427239bf41a1:300000
#checkpoint = 000000000598cbbb1e79057b79eef828c495d4fc31050e6b179c57d07d00367c:400000
#checkpoint = 000000000001a7c0aaa2630fbb2c0e476aafffc60f82177375b2aaa22209f606:500000
#checkpoint = 000000000000624f06c69d3a9fe8d25e0a9030569128d63ad1b704bbb3059a16:600000

cores

This value can have a significant effect on block and transaction validation performance and does not affect other operations. It is typically best to leave it at zero (default). However with a large number of cores it may be worth experimenting with limiting parallelism, at least following chain validation.

priority

A value of true improves validation performance. If the node is consuming too much CPU (e.g. causing slow response in other applications) this can be set to false.

use_libconsensus

This requires that libbitcoin-consensus is linked in the build. This causes the satoshi client's consensus code to be used for script validation (only). Depending on compiler, optimizations and platform this can reduce performance or improve it. Linux performance is typically better with this set to false and Windows performance may be significantly better with it set to true.

reorganization_limit

Valid blocks in a weak branch are held in memory (block pool). When the block that connects to the strong chain falls below this depth it is pruned, along with all of its descendants. This effectively limits the depth of possible reorganization. This value can be set to very high value though that causes increased memory consumption.

block_version

This is not currently used for block creation (not implemented). When transactions are validated independent of a block they must be validated under the assumption that they will become populated into a block. Due to the implementation of rules (soft forks) that invalidate what otherwise would have been valid transactions, it is important to know under what rules unconfirmed transactions are to be validated. This value acts as the block version number for unconfirmed transaction validation. This should be set to the value of the block version anticipated by the configured forks.

checkpoint

Blocks at or below the highest checkpoint are not fully validated. This can significantly increase initial block download. It is recommended that the chain be validated and checkpoints recorded for future use. Relying on checkpoints from third parties basically defers validation of the chain to those parties.