Уведомляя все узлы, которые новый блок имеет (возможно) было найдено может быть достигнуто путем вещания заголовков блоков.

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

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

Правило сети является то, что узлы должны только вперед блоки один блока были полностью проверены. Это означает, что узел должен получить блок, в полном объеме, прежде чем направить его коллега. Он также должен полностью проверить блок. Все это добавляет к латентности.

Кроме того, это означает, что клиенты SPV не могут пересылать блоки. Если полная проверка не требуется, SPV клиент на смартфон, который подключен к Wi-Fi и имеет > 95% заряд батареи может быть установлен, чтобы помочь блокам вперед. Это позволит улучшить избыточность сети.

Там нет необходимости для полной проверки блоков для того, чтобы подтвердить, что блок был полностью опубликован. Блок Военнопленный по своей природе действует как защита от DDOS.

Я предлагаю два новых сообщений "chaintip" а также "newblock",

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

Когда узел получает новый блок, он направит его всем узлам, имеет свой родительский набор в chaintip, используя newblock сообщения.

Блок разбит на несколько "newblock" сообщение следующего формата:

int256 blockid
Int32 message_index = начинается с нуля для каждого блока
Блок заголовка (или пустой массив для message_index > 0)
кодируются Merkle ветвь (ов)
varint tx_count
TXS [tx_count]: сделки

Сообщение требуется либо содержать ровно одну транзакцию или имеют длину меньше, чем 8kB. Это означает, что блок разбивается на множество мелких частей. Крупные сделки все еще могут быть отправлены, но послали в их собственном сообщении.

Каждое сообщение содержит дополнительную информацию Merkle ветви, необходимую для проверки всех операций в сообщении. Чем больше сделок, отправляемых в одном сообщении, тем меньше Merkle информация требуется. Кодирование будет аналогично кодировке merkleblock но модифицирован таким образом, что информация передается в ветви предыдущих сообщений не должна быть повторно отправлена. 

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

Поскольку блок разбивается на части, весь блок не должен быть принят до того, как узел может начать переадресации сообщений newblock по отношению к аналогам. Это сокращает время ожидания. 

Пир может, посылает новое сообщение chaintip информировать коллега, сколько сделок он получил для нового блока. Сверстники бы не вперед newblock сообщения для сделок, которые он уже имеет.

Сообщение chaintip может быть использован для указания, что он не хочет, не более newblock сообщений от конкретного партнера, отправив chaintip с графом транзакций разосланный всем из них. Это будет по-прежнему получать newblock сообщения, если другой блок был найден.

Если узел не посылает по меньшей мере один chaintip сообщения, он никогда не будет получать newblock сообщения.