Перед тем, даже с учетом разработки RFC для Bitcoin, я бы сказал, что есть два очень разных суб-протоколы в Bitcoin, которые должны быть выделены и документированные отдельно. Они, конечно, могут осуществляться по отдельности, но при реализации как на чистый клиент, "ДОЛЖЕН" быть реализованы вместе.

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

Другой RFC должен определить транспорт равный-равному в настоящее время реализуется в клиенте Satoshi, и отдельные сообщения и ожидания. Этот документ должен охватывать ретрансляцию, как / когда реле / ​​не реле и т.д., а также то, что поддерживать узлы данных и нюансы для запроса данных и рекламы своей доступности по отношению к аналогам. Только на этом уровне должны быть какие-либо отношения между операционными издержками и сообщение должно быть передано ли.

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