Это мое понимание:

В любой момент, ваш клиент будет знать хэш кончиков всех цепей он знает о (есть больше, чем один, как вы должны справиться с цепным вилком). При запуске, вы посылаете все эти советы в команде "getblocks. Сообщения в Bitcoin все очень плохо по имени. «Getblocks» не получает блоки на всех; это объявление вашему партнеру блоков вы имеете.

Пир будет смотреть на цепи советы у вас есть и посмотрим, кто из них падает на то, что он считает текущий "Лучший" цепь. Это возвращает «и» с N блоков хэш, которые следуют за лучший. Хэш блоков не думает, что находятся на самой лучшей цепи будет проигнорированы. Вот дополнительные бит: если он бежит из космоса в «и» перед запуском из блоков отмечает последний блок хэш он отправляет вас в качестве "продолжение хэш",

Ваш клиент затем начинает захватывая эти «и» предложил блоки с помощью «GetData» для полного блока или «getheaders» для только заголовка.

Пир будет реагировать нормально большинство запросов «GetData» вы посылаете. Тем не менее, когда вы запрашиваете хэш это отмечалось ранее, как "продолжение хэш"; он затем посылает «и», содержащие хэш, что он считает текущую лучшей цепь.

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

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

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

https://github.com/andyparkins/additup