Soft Fork

Представим Анну и Павла, каждый из которых проверяет Bitcoin на собственном компьютере. Анна обновила программу, Павел пока нет. Появляется изменение, похожее на BIP66: цифровые подписи, подтверждающие право потратить определённые биткоины, должны иметь более строго заданный формат. Некоторые ранее допустимые способы кодирования больше не разрешены. Платёж с правильной подписью в новом обязательном формате проходит эту проверку у обоих. Но если подпись использует кодирование, которое раньше разрешалось, а теперь запрещено, Анна её отклонит, тогда как Павел ещё может принять. Предполагается, что платёж отвечает всем остальным правилам. В этом суть Soft Fork: новые правила запрещают дополнительные случаи, не разрешая ничего из того, что запрещали старые. Пока майнеры создают блоки по более строгим правилам, оба могут продолжать следить за цепочкой. Однако Павел сам не проверяет добавленное условие. Поэтому Soft Fork позволяет менять Bitcoin без одновременного обновления всех узлов. Это не делает проверки старой программы столь же полными, как у новой, и само по себе не создаёт вторую валюту. [1] [6]

Full Node — компьютер, который самостоятельно проверяет правила Bitcoin. Выбирая между допустимыми ветвями, он сравнивает накопленную работу, подтверждённую майнингом, а не голоса сторонников. Старый полный узел может следовать цепи, потому что обновлённые майнеры обычно создают приемлемые для него блоки. Но дополнительное условие он не проверяет: ветвь с большей работой, нарушающую новое правило, он может принять, а новые узлы — отвергнуть. Для новой гарантии нужно обновить собственный валидатор. Получение платежа, распознавание формата и полная проверка консенсуса различны. [1] [12]

BIP — это пронумерованное техническое предложение. Его публикация ещё не меняет сеть: нужно разработать и проверить программу, а пользователям — решить, будут ли они её запускать. Mainnet — основная сеть Bitcoin, где переводят настоящие биткоины. Активация определяет, с какого момента обновлённые узлы начнут требовать соблюдения нового правила. Поэтому наличие кода в программе ещё не означает его применения при проверке блоков. В описанных здесь процедурах lock-in означает, что условие для последующей активации выполнено; само правило пока может не действовать. Узел проверяет его только в состоянии ACTIVE. Это состояние он вычисляет по предыдущим блокам своей ветви. Если реорганизация изменит эту историю вблизи границы активации, результат тоже может измениться. Поэтому две программы с разными параметрами активации могут в один момент принимать разные блоки. [2] [15]

Майнер строит блок на предыдущем блоке, который также называют родительским. Без его проверки можно зря потратить работу на ветвь, которую другие узлы отклонят. В июле 2015 года некоторые майнеры сигнализировали BIP66, но недостаточно проверяли родительский блок. Они продолжили недействительный блок, создав 4 июля шестиблочную недействительную ветвь, а на следующий день ещё одну. Обновлённые узлы их отвергли. Версия — заявление майнера, а не доказательство независимой проверки шаблона, родителя и транзакций. [6] [14]

Чтобы узнать, какие правила действительно применяет ваш узел, начните с версии программы и сведений, которые возвращает он сам. В зависимости от версии команды getdeploymentinfo и getblockchaininfo сообщают о внедрённых изменениях и цепочке. Вместе с документацией выпуска, высотой активации и журналами они помогают отличить подготовленное правило от уже действующего. Веб-обозреватель блоков показывает взгляд другого сервиса, а не доказывает, что проверяет ваш компьютер. Hashrate измеряет вычислительную мощность майнинга. Он не даёт майнерам права обходить правила вашего узла: в состоянии ACTIVE обновлённый узел отклонит блок, нарушающий новое условие, даже если за ним стоит большинство мощности. Устойчивость разделения зависит также от накопленной работы ветвей и их экономического использования. Простая отмена действующего ограничения вновь разрешила бы блоки, которые сейчас недействительны, а значит, была бы изменением типа Hard Fork. До активации параметры можно изменить согласованным выпуском программы, но и такое изменение не установится само на чужих узлах. [1] [15] [16]

V(старое) содержит все блоки, принимавшиеся до обновления. Soft Fork есть лишь когда V(новое) лежит внутри: новый узел отвергает дополнительные случаи, а каждый новый действительный блок проходит старые проверки. Термин описывает совместимость валидности, не малый масштаб, безопасность или общественное согласие. Увеличить видимый старым узлам лимит либо разрешить ранее недействительную трату — значит расширить множество и обычно сделать Hard Fork. [1] [17]

Более строгие правила могут добавлять новые возможности. BIP66 уточнил DER — формат кодирования данных подписи. BIP65 и BIP112 добавили временные условия траты к отдельным командам NOP, которые раньше ничего не требовали. SegWit ввёл программы witness и данные проверки witness, включая подписи. Позднее Taproot использовал их зарезервированную версию 1. Старые узлы не проверяют соответствующие новые условия. Anyone-can-spend описывает этот ограниченный взгляд, а не способ обойти обновлённые узлы и потратить чужие деньги. SegWit также криптографически связывает данные witness с блоком через witness commitment. Эта связь записана в coinbase-транзакции, первой транзакции с вознаграждением майнера, и сохраняет совместимость со старыми правилами базового блока. [6] [5] [7] [8] [12]

Бит имеет значение 0 или 1. Отдельные биты в nVersion, поле версии заголовка блока, могут сигнализировать о готовности майнера. BIP9 назначает каждому внедрению имя, конкретный бит, время начала и крайний срок. Первоначальная процедура mainnet оценивает периоды по 2016 блоков. Если в состоянии STARTED сигнал подадут хотя бы 1916 блоков, то есть 95 %, следующий период перейдёт в LOCKED_IN. После ещё одного периода ожидания наступает ACTIVE. Если условие не выполнено до крайнего срока, процедура может завершиться в FAILED. Начальное состояние до запуска называется DEFINED. Каждый узел вычисляет эту последовательность по предыдущим блокам. Поэтому собственное поле nVersion блока не определяет, применяется ли к нему новое правило. Сигналы помогают согласовать переход, а не голосовать за допустимость отдельных блоков. После достижения lock-in дальнейшие сигналы уже не меняют результат этой процедуры. [2]

Versionbits позволяет майнерам сигнализировать о готовности, но не переписывать правила других узлов. BIP8 использует высоты блоков вместо временных границ. Если lockinontimeout имеет значение true и развёртывание ещё не достигло lock-in, последний период может перейти в MUST_SIGNAL с обязательной сигнализацией. BIP148 требовал от участвующих узлов отклонять блоки, не сигнализировавшие SegWit; BIP91 использовал более низкий порог майнерской сигнализации для координации перехода. Если применение правил, hashrate и экономическое принятие расходятся, цепочка может разделиться. Поэтому выбор способа активации связан с компромиссами безопасности. [11] [9] [10] [17]

P2SH (BIP16) позволяет отправить средства на хеш скрипта — программы с условиями их последующего расходования. При внедрении в 2012 году сигналы в coinbase-транзакциях помогали оценить готовность майнеров. Однако сами новые проверки начинали действовать с заданной границы временных меток блоков: сигнализация не заменяла проверку. Coinbase — первая транзакция блока, содержащая вознаграждение майнера. Следующие изменения использовали версию блока и пороги сигнализации. BIP34 обязал записывать в coinbase высоту блока, его положение в цепочке. BIP66 ужесточил формат подписей DER, а BIP65 ввёл CHECKLOCKTIMEVERIFY — проверку самого раннего времени или высоты, допускающей расходование средств. Постепенное увеличение номера версии затрудняло параллельное внедрение независимых изменений, поэтому BIP9 ввёл отдельные биты. В 2016 году на высоте 419328 одновременно активировались BIP68, BIP112 и BIP113, но они относятся к разным временным условиям. BIP68 вводит относительное ожидание с подтверждения расходуемого выхода. BIP112 позволяет требовать это ожидание в скрипте через CHECKSEQUENCEVERIFY, или CSV. BIP113 меняет временную основу абсолютной блокировки транзакции: вместо временной метки проверяемого блока используется Median Time Past, медиана временных меток предыдущих 11 блоков. Совместная активация не означает, что все три предложения вводят одну и ту же относительную блокировку. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit активировался на высоте 481824 в августе 2017 года. Он отделил проверочные данные witness, в том числе подписи, от части транзакции, по которой вычисляют её идентификатор txid. Почему это важно? При старом кодировании можно было изменить представление подписи, а вместе с ним и идентификатор транзакции, не меняя получателя и сумму платежа. Такая возможность называется malleability, или пластичностью транзакции. Изменение только witness-данных не меняет txid; однако этим способом не исправляются входы, которые по-прежнему используют старый формат. Старый узел видит транзакцию без witness и рассматривает программу witness v0 как anyone-can-spend. Обновлённый узел дополнительно проверяет witness и дайджест подписи — отпечаток подписываемых данных. Witness commitment в выходе coinbase криптографически связывает witness-данные с блоком, позволяя полной проверке обнаружить их изменение или пропуск. Weight, вес данных при подсчёте вместимости блока, увеличил эффективную вместимость. Базовый блок, видимый старому узлу, остался в исходном пределе одного мегабайта. [8]

Key-path позволяет трату с подписью для выходного ключа; script-path требует выполнения условий раскрытого скрипта. Schnorr — схема подписи, Tapscript — язык этих скриптов. BIP341 и BIP342 определяют расходование через key-path и script-path с подписями Schnorr и Tapscript для нативных выходов SegWit с 32-байтовой witness-программой версии 1. Старый узел видит anyone-can-spend: совместимость сохраняется, полная проверка — нет. Speedy Trial использовал изменённый BIP9, порог 1815/2016 (90 %) и минимальную высоту 709632. Taproot активировался там 14 ноября 2021 года. Правила и способ активации надо оценивать отдельно. [12] [13] [16]