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

Кто-то пишет новую реализацию Bitcoin может сосредоточить свою энергию на то, что очень важно, чтобы получить право против чего-то, что "только что произошло" быть сделано таким образом, и можно было бы сделать иначе без вредного эффекта.

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

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

Быть по сему. Но, как Bitcoin реализации должны выйти за рамки традиционного "Программное обеспечение на ПК" (Думают POS терминалы, встроенные системы, смарт-карты, выделенные узлы кремния и т.д.), без спецификации, чтобы проверить против, это очень трудно гарантировать качество и правильность.