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

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.