Soft Fork

アップグレード前にルールによって受け入れられたすべてのブロックに V(old) のマークを付けましょう。この変更は、V(new) が V(old) 内にある場合にのみソフト フォークになります。新しいノードは次のクラスのブロックを拒否しますが、新しいルールに準拠するブロックは古いチェックにも合格します。この名前は、変更の規模、安全性、社会的適合性ではなく、有効性ルールの適合性を表しています。古いノードに表示される制限を増やすか、以前は無効だった支出を許可すると、プールが拡張され、通常はハード フォークが必要になります。 [ビットコイン開発者ガイド — コンセンサスルールの変更] [ビットコインオプテック — ソフトフォークのアクティブ化]

更新されたマイナーが認識するブロックを定期的に作成するため、古いフル ノードは引き続きチェーンをたどることができます。ただし、追加された条件はチェックされません。より多くの作業を伴うブランチが新しいルールに違反する場合、古いノードはそれを受け入れることができますが、更新されたノードはそれを拒否します。新しい保証が必要な場合は、独自の検証ソフトウェアを更新する必要があります。ウォレットが支払いを受け入れる能力、フォーマットの互換性、および完全なコンセンサス検証は別のものです。 [ビットコイン開発者ガイド — コンセンサスルールの変更] [BIP 341 — Taproot デプロイメント]

ビットコインは、いくつかの手法を使用してサブセットを作成しました。 BIP66 は、古いルールでは受け入れられていた非厳密な DER 署名を禁止しました。 BIP65 と BIP112 では、古いインタプリタが何もせずに成功したとみなす条件が NOP オペコードに追加されました。 SegWit と Taproot は、監視プログラムの予約バージョンに意味を与え、古いノードでは誰でも使用できると見なします。同時に、設計では新しい制御の回避を防止する必要があります。したがって、SegWit はコインベース経由で証人データをコミットし、古い基本ブロック ルールを保存しました。 [BIP 66 — 厳格な DER 署名] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — 隔離された監視] [BIP 341 — タップルート展開]

コードには、メインネットで有効になるずっと前に非アクティブなルールが含まれている場合があります。 BIP およびチェックされた実装はデプロイメントではなく、デプロイメント パラメーターはロックインではなく、ロックインは将来の施行を計画するだけであり、指定されたブロックのチェックを意味するのは ACTIVE 状態のみです。各ノードは、自身のブランチの祖先から状態を計算します。境界での再編成により再計算が行われる可能性があり、異なるパラメータを持つソフトウェアが互換性のないルールの強制を開始する可能性があります。 [BIP 9 — タイムアウトと遅延のあるバージョン ビット] [ビットコイン コア — versionbits.cpp]

BIP9 は、名前、ビット バージョン、開始時刻、およびタイムアウトを展開に割り当てます。元のメインネットのバリアントは、2,016 ブロック後の期間を評価します。少なくとも 1,916 のシグナリング ブロック、つまり 95% の後、STARTED から LOCKED_IN に移行し、1 周期待ってから ACTIVE になります。そうしないと、失敗してしまう可能性があります。完全なシーケンスは、DEFINED、STARTED、LOCKED_IN、ACTIVE、FAILED です。ブロックの状態は、ブロック自身の nVersion ではなく、その先祖に依存し、ロックイン後のシグナリングによって結果が変更されることはなくなりました。 [BIP 9 — タイムアウトと遅延を伴うバージョン ビット]

バージョンビットはマイナーの準備状況を示し、移行を調整します。マイナーにコンセンサスの永久的な所有権を与えるものではありません。 BIP8 は高さを使用し、lockinontimeout を使用すると、最後のウィンドウでシグナリングを強制できます。一方、BIP148は、参加ノードに対し、非SegWitシグナリングブロックを拒否するよう命令した。 BIP91 は、この圧力に対応するためにマイニングのしきい値を引き下げました。強制的なアクティベーションは、ノード、ハッシュ レート、経済的採用が異なる場合にチェーンを分割する可能性があるため、アクティベーション方法ですらセキュリティを侵害することになります。 [BIP 8 — 高さによるロックインを備えたバージョン ビット] [BIP 148 — SegWit の強制アクティブ化] [BIP 91 — 閾値の削減 SegWit MASF] [ビットコイン オプテック — ソフト フォークのアクティブ化]

BIP16 に基づく P2SH は、コインベースのシグナリングと時間制限によって 2012 年にアクティブ化されました。 BIP34 は、コインベースのブロック バージョンと必須の高さのしきい値を使用しました。同じ整数プロシージャは、BIP66 では厳密な DER を実行し、BIP65 では CHECKLOCKTIMEVERIFY を実行しましたが、バージョン値を消費し、同時デプロイメントを実行できませんでした。したがって、BIP9 では独立したビットが導入されました。その後、BIP68、BIP112、BIP113 は、2016 年の高さ 419,328 で相対ロックタイムと CSV として一緒にアクティブ化されました。 [BIP 16 — スクリプトハッシュへの支払い] [BIP 34 — ブロック v2、コインベースの高さ] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — 厳格な DER 署名] [BIP 112 —チェックシーケンス確認]

SegWit は、2017 年 8 月に 481,824 でアクティブ化されました。古いノードは、監視データのないトランザクションを認識し、監視 v0 を誰でも使用できると見なします。更新された検証証人、新しい署名ダイジェスト、および耐展性ルール。コインベースの出力でデータを監視するというマークルの取り組みにより、マイナーが検出されずにデータを変更したり省略したりすることがなくなります。重み付け課金により、古いノードから見える基礎となるブロックが 1 メガバイトの古い制限を超えることなく、実効容量が増加しました。 [BIP 141 — 隔離された証人]

BIP341 および BIP342 は、Schnorr 署名と Tapscript を使用したプログラム バージョン 1 のキーパスとスクリプトパスの支出を監視します。古いノードは再び予約されたプログラムを誰でも使用できるものとして扱います。サブセットは保存されますが、完全な検証は保存されません。メインネットは、しきい値が 2,016 ブロック中 1,815 (90%)、最小アクティベーション高さが 709,632 である、修正された BIP9 Speedy Trial を使用しました。 Taproot は 2021 年 11 月 14 日にその中でアクティブ化されました。 Taproot のルールとその有効化方法は、監査上の 2 つの別個の質問です。 [BIP 341 — Taproot デプロイメント] [BIP 342 — Tapscript] [Bitcoin Core 0.21.1 リリースノート — Taproot デプロイメント]

2015 年 7 月に BIP66 がアクティブ化されたとき、一部のマイナーは新しいバージョンを通知しましたが、マイニング対象の親ブロックを十分に検証しませんでした。彼らは無効なブロックを拡張し、7 月 4 日に 6 ブロックの無効なブランチを作成しました。翌日、さらに短い出来事が続いた。更新された検証ノードは両方のブランチを拒否しました。バージョン番号またはビットはマイナーによる主張であり、マイナー自身がテンプレート、親、およびトランザクションを検証したことを証明するものではありません。 [BIP 66 — 厳格な DER 署名] [Bitcoin.org — 2015 年 7 月の BIP66 チェーン フォーク アラート]

ACTIVE 状態では、更新されたノードは、ハッシュ レート シェアに関係なく、問題のあるブロックを拒否します。恒久的な分裂が生じるかどうかは、支部の働きとその経済的利用に依存します。単に制限を削除すると、現在の無効なブロックが再び有効になるため、ハード フォークになります。パラメータまたはコードは、アクティベーション前に調整されたリリースに置き換えることができます。オペレーターは、自身のバージョン、getdeploymentinfo または getblockchaininfo、正確なパラメーター、アクティブ化の高さ、およびログを検証します。シグナリング グラフもエクスプローラー ラベルもローカル検証に代わることはできません。 [ビットコイン開発者ガイド — コンセンサス ルールの変更] [ビットコイン コア — versionbits.cpp] [ビットコイン コア 0.21.1 リリース ノート — Taproot デプロイメント]