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

Я считаю, что Satoshi клиент последняя контрольная точка находится примерно в блок 180000. Отдельные узлы будут отвергать любые представления блока до блокировки 180000, если он уже имеет действующую сеть.  Кроме того, когда не bootstapping (не blockchain) отдельные узлы будут отвергать любые цепи, которые печатные хэш не совпадают с контрольной точкой хэш.  
На редактирования:
Было бы перехитрили просто прочитать код.

https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp


Так в настоящее время первый контрольно-пропускной пункт находится в блоке 11,111 и последний находится в 193,000. Один потенциальный район "атака" (И это будет относительно слабым) является то, что контрольные точки являются редкими. Существует ~ 30К блоков между контрольно-пропускных пунктах. Таким образом, "плохой узел" может затопить узел, который самозагрузка (здание исторического blockchain). Теперь, как только узел попадает на контрольно-пропускной пункт (т.е. блок # 11111) плохой узел не сможет завершить эту цепочку. Однако плохой узел мог переключаться и обеспечить правильные блоки (возможно, через другой узел) через блок # 11,111, а затем обеспечить еще 22,222 плохие блоки.

Так как блоки могут быть построены, чтобы иметь большое количество сделок в "плохой узел" может значительно повысить требования к обработке хороших узлов. Это может быть смягчено путем обеспечения полного "контрольно-пропускной пункт списка" каждый blockhash через последний контрольно-пропускной пункт. (То есть выше код будет иметь записи для блоков 1 через 193,000). На редактирования: Мне нравится идея Гэвина лучше. По многим причинам, было бы полезно, если протокол позволяет вытягивать только блок заголовков. Он решает не только эту слабую атаку (которая не должна быть приоритетом, чтобы исправить), но и делает протокол более надежной.



В общих узлах относительно "наивный" в работе с узлами плохого поведения. Скорее всего, как раз идет о методе сбора сверстникам необходимо будет расширить. По существу, узел будет отслеживать все свои узлы плюс всех известных, но не связанные узлы. Узлы, которые предоставляют неверные данные, постоянно спам уже известные данные, имеют высокую латентность, ЧерезРетранслы значительно медленнее, чем сверстники, и т.д. могут быть засчитаны вниз и когда они падают ниже порог узел будет посылать им сообщение об ошибке, и игнорировать их в течение некоторого периода времени. Узел может затем попытаться подключиться к новому известному, но еще не используются узел. Код в настоящее время делает немного об этом, но она может быть расширена, чтобы сделать протокол более закаленным.  

Узлы могут также использовать цифровые подписи, которые бы помочь в построении "Сеть доверия", Например, если я доверяю MtGox и blockchain.info я мог бы отметить их "узел открытых ключей" как доверенный. Они забиты выше, протокол может быть расширены таким образом, когда я запрашиваю доверенный узел для других узлов не только дает мне список, но и их оценку. Целый "если я вам доверяю, то я могу доверять людям, вы доверяете слишком" концепция.