Какие блоки станут контрольными точками?

По крайней мере, в Bitcoin Core — нет. Контрольные точки являются устаревшими и, вероятно, в какой-то момент будут удалены.

Контрольные точки изначально были введены как способ пропустить подписи в исторической цепочке, не будучи уязвимым для принятия альтернативной истории. Эта роль теперь уступила место assumevalidконцепции (хэш блока, который, как известно, хорош, но не препятствует принятию другой цепочки).

Контрольные точки также использовались в качестве эвристики, чтобы узнать, какие заголовки блоков являются приемлемыми, прежде чем проверять весь блок. Эта роль была удалена с синхронизацией по заголовкам в версии 0.10. Теперь мы загружаем блок только после того, как уже знаем, что его доказательство работы и сложность являются приемлемыми.

Они также использовались в качестве показателя прогресса проверки (поэтому Bitcoin-Qt может отображать индикатор выполнения во время проверки). Эта роль была заменена только статистическими данными, которые не влияют на проверку.

Единственное, для чего по-прежнему служат контрольные точки, — это предотвращение атаки заголовков с низкой сложностью, когда ваш узел получает спам из-за большого количества длинных ветвей цепочки с низкой сложностью, из-за чего ему не хватает памяти. Из-за существующих чекпоинтов (до высоты 295000) это уже очень затратная атака.

Вы можете найти список в исходном коде биткойнов . Это текущие контрольные точки (из версии git c091b99):

    checkpointData = (CCheckpointData) {
        {
            { 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d")},
            { 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6")},
            { 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20")},
            {105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97")},
            {134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe")},
            {168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763")},
            {193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317")},
            {210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e")},
            {216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e")},
            {225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932")},
            {250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214")},
            {279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40")},
            {295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")},
        }
    };

На самом деле не имеет значения, как они выбраны, но обратите внимание на следующие комментарии , найденные в источнике:

/**
 * What makes a good checkpoint block?
 * + Is surrounded by blocks with reasonable timestamps
 *   (no blocks before with a timestamp after, none after with
 *    timestamp before)
 * + Contains no strange transactions
 */

В любом случае, пока они вставлены через равные промежутки времени, все в порядке. Этот ответ дает намек на то, какова их цель.