Что происходит, некоторые разработчики создают изменения и отправить запрос на нагрузочный. Код затем рассмотрен, и если достаточно постоянных авторов согласны, что изменения должны быть объединены, то они будут объединены. Для того, чтобы это произошло, хотя, несколько вещей, как правило, должно произойти. Во-первых, как общее правило, если изменение консенсуса не имеет соответствующего BIP, который тщательно разъясняются детали на техническом уровне, что кто-то может осуществить это, то изменение отвергается. Во-вторых, она должна быть реализована в виде вилки с параметрами развертывания. Это означает, что, когда программное обеспечение отпущено, изменения не являются активными. Шахтеры будут сигнализировать признание и приведение в исполнение изменения (как правило, через блок номеров версий) и после того, как передача сигналов прошло определенное пороговое значение, то программа будет автоматически переключаться на новые правила.

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

Там нет BIP требует, чтобы вилки требуют сигнализаций, и нет никакого фактического голоса (сигнализация не голос). Однако, с самим первой официальной мягкой вилки (Satoshi сделал вещи обратно в тот же день, что могло бы вызвать вилку, но не потому, что община была еще маленькой) был BIP 34. С тех пор, все вилки (изменения консенсуса) потребовали развертывания. Текущая система развертывания BIP 9 VersionBits.

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

Не обязательно. Wladimir не единственный человек с фиксацией доступа. Есть много областей коды, для которых он не имеет опыта в, и он полагается на других участниках, чтобы оценить код и рекомендовать его для объединения. Там было несколько Напряжения Просьбы слита где Wladimir не было никаких комментариев и слит после несколько ACKs, и другие, где у него не было никаких замечаний и изменения было слито кем-то другим. Я уверен, что он также NACK'ed вещи, которые до сих пор получил слиты.

Он не единственный человек, который NACK'ing эти предложения. Почти все, что является частью организации Bitcoin на Github (не все коммиттеры) было отвергая эти предложения.