Reorg

Анна получает 20 000 сатоши — мелких единиц биткоина. Кошелёк показывает одно подтверждение: платёж находится в блоке, принятом её узлом. Затем узел узнаёт о конкурирующей допустимой ветви, в которой этого платежа пока нет. Когда она подтверждает больше накопленной работы майнинга, узел переходит на неё. Такая замена части истории называется Reorg. Платёж Анны может снова ждать подтверждения, хотя никто не крал её ключи и не менял подпись. Решает не голосование и не просто число блоков, а chainwork: сумма работы, которую каждый блок подтверждает в соответствии со своей сложностью. Недопустимую ветвь узел отвергнет, даже если работы в ней больше. [1] [4]

Дальнейшее зависит от новой ветви. Если платёж Анны есть и в ней, он остаётся подтверждённым, хотя число подтверждений может измениться. Иначе Bitcoin Core может попытаться вернуть его в Mempool — временный список неподтверждённых транзакций, ожидающих блока. Возврат не гарантирован. Выход предыдущей транзакции содержит запись суммы и условий её расходования. Новая ветвь могла уже потратить те же средства в другой транзакции; может отсутствовать предыдущий выход, который расходуется, либо не выполняться временные или другие условия приёма. Поэтому вновь ожидающий платёж отличается от платежа, который новая история больше не допускает. [1]

Одно подтверждение означает блок с платежом. Каждый последующий блок добавляет подтверждение и работу, которую конкурирующей ветви придётся превзойти. Таким образом, платёж в последнем блоке имеет одно подтверждение; чем глубже он в принятой истории, тем труднее обычно заменить эту её часть. Но никакое конечное число подтверждений не гарантирует математически, что замена невозможна. Продавцы и биржи поэтому выбирают срок ожидания с учётом суммы платежа и приемлемого риска. [3] [5]

Сам по себе Reorg не доказывает атаку. Два майнера могут почти одновременно найти блоки с общим предшественником. Информация распространяется не мгновенно, поэтому узлы некоторое время следуют за разными концами цепочки. Когда одна допустимая ветвь накопит больше работы, узлы переходят на неё; оставленный блок — это Stale Block. Однако тот же механизм можно использовать для атаки Double Spend: злоумышленник пытается навязать историю, в которой те же средства отправлены другому получателю. Поэтому важно выяснить причину перехода и то, какие платежи он изменил. [4] [5]

При Reorg узел сохраняет прежние правила и выбирает между соответствующими им историями. Hard Fork меняет правила допустимости блоков, так что старое и новое ПО могут по-разному оценивать один и тот же блок. Следовательно, реорганизация сама по себе не создаёт новую валюту и не переписывает правила Bitcoin. Следующие главы объясняют техническую сторону смены истории. [4]

Tip — последний блок ветви, которую узел сейчас принимает. Точка ветвления — последний общий блок текущей активной цепочки и альтернативной ветви. Глубину Reorg обычно описывают числом блоков с конца активной цепочки, которые необходимо отключить, чтобы вернуться к этому общему предку. Reorg одного блока заменяет вершину, более глубокий отменяет несколько подтверждённых блоков. Глубина зависит от состояния конкретного узла. [1]

Full Node самостоятельно проверяет правила. Названия функций ниже описывают их реализацию в Bitcoin Core. Bitcoin Core не выбирает просто самую высокую или популярную ветвь. При активации цепочка-кандидат должна соответствовать правилам консенсуса узла; больший chainwork не делает невалидный блок валидным. FindMostWorkChain выбирает кандидата с наибольшей работой, о невалидности которого ещё не известно. Это пока не означает полной проверки: дополнительные проверки выполняются при подключении блоков в ActivateBestChain. Ветви с известной невалидностью исключаются. [1]

UTXO — неизрасходованный выход транзакции; набор UTXO объединяет такие доступные выходы. Данные undo хранят сведения для отмены последствий блока. DisconnectTip и связанная логика проверки отменяют последствия отключённых блоков в обратном порядке. Потраченные UTXO восстанавливаются, а выходы, созданные удалённым блоком, теряют подтверждение. Поэтому Bitcoin Core хранит данные отмены: он должен точно восстановить набор UTXO в точке ветвления. [1]

Rollback здесь означает возврат к состоянию до отсоединённых блоков; chainstate — рабочее состояние узла, соответствующее принятой истории. После отката ConnectTip подключает блоки ветви с большим chainwork в прямом порядке. Каждая транзакция заново проверяется относительно восстановленного набора UTXO и правил, действующих на данной высоте. Результат — chainstate, соответствующий одной конкретной истории, а не смесь транзакций обеих ветвей. [1]

Coinbase Transaction — первая транзакция блока, назначающая майнеру награду. Высота h обозначает положение блока в цепочке. Транзакция coinbase — исключение: после отключения она не возвращается в mempool. По правилам консенсуса выход coinbase, созданный на высоте h, можно впервые потратить в блоке h + 100. При вершине h + 99 исходный блок имеет 100 подтверждений, и условие зрелости позволяет включить трату в следующий блок. Если Reorg удаляет блок с coinbase, награда этого блока исчезает из активного chainstate. Невалидными могут стать и зависимые транзакции, опиравшиеся на удалённую историю. [1] [2] [3]

Далее приведены названия функций конкретной версии программы, а не дополнительные действия пользователя кошелька. В Bitcoin Core v29.0 шаги заданы явно: FindMostWorkChain находит кандидата с наибольшим chainwork без известной невалидности, ActivateBestChainStep может отключить текущую вершину, ConnectTip проверяет и подключает альтернативные блоки, а MaybeUpdateMempoolForReorg заново проверяет транзакции отключённых блоков. Активация может выявить невалидность кандидата и продолжить поиск другой ветви. Крупный Reorg требует обработки большего числа отключённых и подключённых блоков, поэтому может увеличить время выполнения ActivateBestChain. [1]