現在のプロセスは、展開された BIP 3 によって管理されます。誰でも提案書を作成できますが、番号が割り当てられ、ドキュメントは BIP 編集者によって公開されます。 BIP は仕様、情報、プロセスに分かれており、ドラフト、完了、展開、終了の各状態を経て、作成者の推奨のままになります。実際の採用は、リポジトリ自体の外部での実装、使用、場合によってはアクティベーションを通じてのみ行われます。 (Specification) (Informational) (Draft)
BIP はビットコインの公開提案文書です。技術的機能、相互運用性ルール、プロセス、推奨事項、または履歴記録を定義できます。リポジトリは設計に安定した参照点を提供し、変更履歴を保存します。 BIP は法律、プロトコル コマンド、または自動更新ではありません。ノードは、実際に実行するソフトウェアに含まれるルールのみを強制します。
「Updated BIP Process」という名前の BIP 3 のステータスは「Deployed」で、BIP 2 に置き換わりました。このプロセスにより、ワークフローが明確になり、編集者の意思決定の余地が制限され、古い Standards Track カテゴリが仕様カテゴリに置き換えられ、ステータスが簡素化されました。同時に、リポジトリは出版媒体およびアーカイブであり、投票システムや承認メーターではないことも明確に述べています。
作業は GitHub の前から始まります。著者は古い提案を検討し、ビットコイン開発メーリングリストで特定のアイデアについて議論する予定です。十分に練られた提案のみが、独自の番号なしのプル リクエストとして送信されます。 BIP エディターは、テキストがテーマに関連しており、適切にフォーマットされており、明らかにアイデアの段階を超えている場合に番号を割り当てます。次に、それをリポジトリにマージして公開します。
仕様 BIP は、機能または相互運用性に関する実装可能な技術ルールを設定します。 Complete 状態になる前に、リファレンス実装と包括的なテスト ベクトルが必要です。情報 BIP では、設計上の問題、推奨事項、または情報が説明されます。プロセス BIP はビットコインに関するプロセスを変更し、展開後は継続的に更新されるプロセス ドキュメントとして機能できます。
ドラフトとは進行中の提案を意味します。 「完了」は、著者が計画された作業が完了したと考えており、採用または実装を推奨していることを示します。仕様 BIPU の実装およびテストに関するドキュメントが必要です。導入とは、文書化されたアクティブな使用を意味するか、プロセス BIP の場合は大まかな合意が必要であることを意味します。 「Closed」は、ドキュメントが現在はアクティブに作業または使用されていないことを示します。歴史のために保存され続けています。
BIP 編集者は、範囲、形式、事前協議、ライセンスと準備状況を確認し、番号を割り当て、メタデータを維持します。 BIP 3によれば、提案が受け入れられるかどうかは彼らが決定するものではないという。したがって、物議を醸している BIP を単に出版しただけでは、その安全性、正確性、人気、コミュニティの合意が確認されるわけではありません。
この数値は主に安定した参照として機能します。 BIP 39 は広く使用されているニーモニック標準であり、BIP 141 は SegWit のルールを記述し、BIP 174 は PSBT を定義し、BIP 50 は 2013 年 3 月の分割の事後調査です。他の番号の付いた BIP はドラフトまたはクローズ済みのままです。この数字自体は、重要性、実装、承認については何も語っていません。
仕様は実稼働実装なしで存在する可能性があり、実験用ソフトウェアはドラフトを実装でき、展開またはアクティベーションは別個のイベントです。合意に基づく変更の場合、その違いは重要です。1 つの BIP では新しいルールを定義でき、別の展開方法でノードがルールの適用を開始できるのは、ソフトウェアとアクティベーション条件が決定した場合のみです。
BIP 141 は BIP 仕様であり、そのルールは SegWit のアクティブ化後にビットコインのコンセンサスの一部となりました。 BIP 174 は、ブロックの有効性を変更せずにウォレットと署名者の相互運用性を実現するフォーマットです。 BIP 50 はこの事件を文書化しています。 BIP 3 自体はプロセス BIP です。したがって、「BIP を受信しました」という文は、タイプによって根本的に異なることを意味する可能性があります。
最新の BIP には、ステータス、タイプ、番号割り当て日、ライセンス、ディスカッション リンク、バージョン、場合によっては要件、置換、および置換提案などのメタデータが含まれています。完了後、より重要な変更がセマンティック バージョニングと同様のバージョンで変更ログに書き込まれます。成熟した仕様に対する下位互換性のない変更は、通常、古い番号の意味を静かに変更するのではなく、新しい BIP を取得する必要があります。
スクリーンショットや古い記事ではなく、必ず公式リポジトリにある現在のバージョンから始めてください。タイプ、ステータス、バージョン、作成者、ディスカッション、依存関係、および変更ログを確認します。次に、関連するソフトウェアのサポートと、コンセンサス設計、展開、アクティベーションを個別に検証します。重要な質問は、「BIP は存在するのか?」ではなく、「BIP は正確に何を規定するのか、誰が実装するのか、そして実際に活動していることを示す証拠は何なのか?」ということです。
理解を深めるには、この項目とあわせて次もお読みください Soft Fork, コンセンサス規則, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. 次の項目からも参照されています Soft Fork, ブロックサイズ戦争, Bitcoin Core.