BIP (Bitcoin Improvement Proposal)

Anna はパソコンで支払いを準備し、別のメーカーのハードウェアウォレットで署名しようとしています。両方のプログラムが受け渡すデータを理解できなければなりません。この問題を扱うのが BIP 174 です。未完成のトランザクションと署名に必要な情報をやり取りする共通形式、PSBT を定めています。開発者は互換性のない形式を別々に考える代わりに、同じ文書に従えます。これが BIP の実用的な役割の一つです。 [8]

番号によって扱う仕事は異なります。BIP39 は復元用の単語を生成し、ウォレットの鍵を導出する出発点となるデータ、seed に変換する方法を記します。BIP 141 は SegWit を記述し、そのトランザクション処理ルールはネットワークでの有効化後に適用されました。BIP 174 はブロックの有効性を変えずに署名用トランザクションの受け渡しを助けます。一方、BIP 50 はネットワークが一時分裂した 2013 年 3 月の事故について、原因と解決を記録しています。すべての BIP が新しい Bitcoin のルールを提案するわけではありません。 [6] [7] [8] [9]

解決策を記述すること、プログラムを書くこと、それを使うことは別の段階です。記述は仕様、コードは実装と呼びます。ウォレットが草案を試験的に実装する場合もあれば、まだ使われているプログラムがない文書もあります。ブロックの有効性ルールを変える場合は、該当ソフトウェアが新ルールの適用を始める「有効化」も必要です。文書の公開だけで、ネットワークのルールを確認するコンピューターである自分のノードが更新されることはありません。 [7] [10]

番号は主に、正しい文書を探し、同じ提案について議論するための目印です。番号が大きいほど優れているとか、更新を勧められているという意味ではありません。番号が付いても未完成のままになったり、取り下げられたりします。サービスがある BIP への対応を宣伝しているなら、どの機能を指すのか、そのソフトウェアの具体的なバージョンで本当に利用できるのかを確認する必要があります。 [2]

著者はまず過去の研究を調べ、開発者による公開メール討論の場、Bitcoin Development Mailing List でアイデアを話し合います。長い文書を書く前に、意見をもらうことで問題が見つかるかもしれません。十分に練った提案は、GitHub の共通保管場所 bitcoin/bips に pull request、つまり文書を取り込んでもらう依頼として提出します。番号を自分で選ぶことはできません。編集者がテーマ、形式、成熟度を確認して割り当てます。 [1]

BIP Editors は公開文書を管理します。事前の議論、説明の明確さ、形式、ライセンスを確認し、番号を割り当て、記録を整えます。それによって、使うべきソフトウェアやノードが受け入れるルールを決める権限が生まれるわけではありません。保管場所に掲載されても、安全性やコミュニティの合意が保証されるものではなく、実際に使うかどうかは各プロジェクトとネットワーク参加者が判断します。 [1]

ニュースに「BIP が承認された」とあれば、文書を開いて何が起きたのかを確かめてください。番号が付いただけなのか、著者が作業を終えたのか、それとも対応機能がすでに使われているのか。ウォレットなら公式文書と公開済みバージョンを調べ、ネットワークのルール変更なら有効化の条件と進捗も確認します。興味深い提案と、今すぐ使える機能を区別するためです。 [10] [2]

現在の手続きを定めるのは、状態が Deployed の BIP 3、Updated BIP Process です。BIP 2 を置き換え、文書の種類と状態を整理しました。そのため、古い記事に出てくる Standards Track や Final は現在の分類と一致しない場合があります。最新のファイルと変更履歴を確認しましょう。保管場所の役割は提案の公開と保存であり、Bitcoin の未来を投票で決めることではありません。 [1] [5]

Specification は相互に対応できるプログラムを作るための技術ルールを記します。完成前には、設計の実現方法を示す、実際に動くプログラムが必要です。これを参照実装と呼びます。テストベクトル、つまり入力例と期待される結果も用意します。Informational は情報、分析、指針を提供します。Process は BIP の公開そのものなど、作業の手続きを定めます。BIP 3 はこの最後の種類に属し、新しい Bitcoin トランザクション形式を定めるものではありません。 [1]

Draft は作業中、Complete は著者が予定した作業を終えて採用を勧める状態です。Deployed は実際の利用が確認されたことを示します。Process では、単なる票数ではなく、議論と根拠のある異論への対応を経た広い合意、所定の rough consensus が成立したことを意味する場合もあります。Closed は開発、推進、利用がすでに行われていない歴史的な文書で、記録として残ります。Deployed でも、すべてのウォレットが対応しているとは限りません。 [1]

冒頭には著者、種類、状態、番号の割当日、ライセンス、議論へのリンクがあります。Requires は必要な別の BIP、Replaces は置き換えようとする提案、Proposed-Replacement は後継候補を示します。Complete になった後の変更は、日付とバージョン番号を付けて Changelog、つまり変更記録に残します。冒頭の Version 欄には、文書の現在のバージョンを記します。従来の設計と互換性のない変更は、原則として新しい BIP にするべきです。同じ番号の意味が知らないうちに変わるのを避けるためです。 [1]