Reorg — це локальна зміна chainstate, а не правил консенсусу Bitcoin. Full Node застосовує власні правила перевірки й активує гілку з найбільшим сукупним chainwork, яка проходить ці перевірки. Якщо вона відгалужується нижче поточної вершини, вузол скасовує зміни UTXO від’єднаних блоків, застосовує альтернативну гілку й повторно оцінює відповідні транзакції щодо mempool.
Bitcoin Core не обирає просто найвищу чи найпопулярнішу гілку. Під час активації ланцюг-кандидат має відповідати правилам консенсусу вузла; більший chainwork не робить невалідний блок валідним. FindMostWorkChain обирає кандидата з найбільшою роботою, про невалідність якого ще не відомо. Це ще не означає повної перевірки: додаткові перевірки виконуються під час приєднання блоків у ActivateBestChain. Відомі невалідні гілки відкидаються. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Точка розгалуження — останній спільний блок поточного активного ланцюга й альтернативної гілки. Глибину Reorg зазвичай описують кількістю блоків активної вершини, які треба від’єднати, щоб повернутися до цього спільного предка. Одноблоковий Reorg замінює вершину, глибший скасовує кілька підтверджених блоків. Глибина залежить від погляду конкретного вузла. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
DisconnectTip і пов’язана логіка перевірки скасовують наслідки від’єднаних блоків у зворотному порядку. Витрачені UTXO відновлюються, а виходи, створені вилученим блоком, втрачають підтвердження. Саме тому Bitcoin Core зберігає дані скасування: він має точно відновити набір UTXO в точці розгалуження. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Після відкату ConnectTip приєднує блоки гілки з більшим chainwork у прямому порядку. Кожна транзакція знову перевіряється щодо відновленого набору UTXO та правил, чинних на відповідній висоті. Результат — chainstate, що відповідає одній конкретній історії, а не суміш транзакцій з обох гілок. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Транзакції з від’єднаних блоків не обов’язково зникають. Bitcoin Core намагається повернути придатні транзакції, окрім coinbase, до mempool. Деякі вже можуть бути в новій гілці, конфліктувати, втратити входи, перестати відповідати часовим умовам або політиці mempool. Тому гаманець має враховувати, що Reorg може скасувати підтвердження. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Транзакція coinbase є винятком: після від’єднання вона не повертається до mempool. За правилами консенсусу вихід coinbase, створений на висоті h, можна вперше витратити в блоці h + 100. Коли вершина перебуває на h + 99, вихідний блок має 100 підтверджень, а умова зрілості дозволяє включити витрату до наступного блоку. Якщо Reorg вилучає блок із coinbase, винагорода цього блоку зникає з активного chainstate. Невалідними можуть стати й залежні транзакції, що спиралися на вилучену історію. [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]
Кількість підтверджень включає блок із транзакцією та всі наступні блоки в поточному активному ланцюзі конкретного вузла. Транзакція в поточній вершині має одне підтвердження. Кожен наступний блок зазвичай збільшує роботу, потрібну для заміни історії, але жодна скінченна кількість підтверджень не створює математично абсолютної остаточності. Біржі й продавці обирають поріг відповідно до суми платежу та своєї моделі ризику. [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]
Короткий Reorg може виникнути природно, коли два майнери майже одночасно знаходять конкурентні блоки й різні частини мережі певний час стежать за різними вершинами; гілка з меншим chainwork стає неактивною. Атака Double Spend навмисно використовує той самий механізм. Технічний процес вибору ланцюга однаковий, відрізняються причина й економічна мета. [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]
Reorg відбувається в межах одного набору правил: вузол обирає між гілками, які вважає валідними. Hard Fork змінює правила валідності так, що старе й нове програмне забезпечення можуть не погоджуватися вже щодо того, чи є блок валідним. Отже, реорганізація сама по собі не змінює консенсус. [Bitcoin Developer Guide — Block Chain]
У Bitcoin Core v29.0 кроки визначені явно: FindMostWorkChain знаходить кандидата з найбільшим chainwork без відомої невалідності, ActivateBestChainStep може від’єднати поточну вершину, ConnectTip перевіряє й приєднує альтернативні блоки, а MaybeUpdateMempoolForReorg повторно перевіряє транзакції з від’єднаних блоків. Активація може виявити невалідність кандидата й продовжити пошук іншої гілки. Великий Reorg потребує обробки більшої кількості від’єднаних і приєднаних блоків, тому може подовжити виконання ActivateBestChain. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Для повної картини прочитайте також Підтвердження, Proof of Work, Stale Block, Подвійна витрата, Full Node, UTXO. На цю статтю також посилаються Підтвердження, Подвійна витрата, Coinbase-транзакція, Soft Fork.