ビットコイン番RFCである"Bitcoin Improvement Proposal"を読んでみよう

どうも。かちおです。
以前書いたように、ビットコインの本質はプロトコルなのですが、そのプロトコルを追加する上で、ビットコインはその仕様をすべて"Bitcoin Improvement Proposal"という方式で提案、投票、管理、告知、同意されています。ここには、たとえばネットワーク上のTCPソケット通信の先頭ヘッダの仕様から、ビットコインを送金するときのQRコードのフォーマットまで、そのすべてが規格として決められています。
そんなビットコインの本質であるBIPを1番から全部解説していこうじゃないか、というのがこの記事の趣旨です。
とりあえず、基本的なビットコインのプロトコル以外はすべてBIPとして提案され可決され、実際に使われるようになっています。
BIPは、すべてMediaWiki形式で、https://github.com/bitcoin/bips にまとめてあります。これを翻訳、意訳しながら書いていきます。

今回読んで見るBIP1は、BIPそのものの説明やBIPの書き方などをさだめたものとなっています。
それでは、以下からBIP0001本文訳です。

BIP 1

  BIP番号: 1
  タイトル: BIP Purpose and Guidelines (訳: BIPの説明とガイドライン)
  著者: Amir Taaki <genjix@riseup.net>
  コメントの状態: なし
  コメントのアドレス: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
  状態: Replaced
  タイプ: Process
  作成日時: 2011-08-19
  更新回数: 2

BIPとはなにか

BIPは、ビットコインの改良の提案をするものです。BIPは、ビットコインのコミュニティに情報を提供したり、ビットコインの新しい機能、仕様、環境、を説明する文書です。
BIPは、機能に対する簡潔な技術仕様と、根拠を示さないといけません。

私達は、BIPが、新しい機能を提案したり、コミュニティが問題を解決するために提案をしたり、ビットコインが向かっていく先を決定したりなどのためのしくみになることを期待しています。
BIPの作者は、コミュニティの反対意見や論文などにも、責任を持って内容の同意を得なければいけません。

BIPは差分管理されたテキストファイルです。BIPの変更の記録は、すべて将来のために残さなければいけません。

BIPの種類

BIPの種類を以下に述べます。

スタンダードトラックBIPと呼ばれる、ビットコインの実装、ネットワークプロトコルや、ブロック、トランザクション、その他Bitcoinを扱う上でのアプリケーションとしての変更などの全てを説明し、解説するBIP。
インフォメーショナルBIPと呼ばれる、ビットコインの設計の問題や、コミュニティの一般的な方向性、を説明するBIP。これは、必ずコミュニティの総意を得る必要はありません。そして、ユーザーもインフォメーションBIPやアドバイスを無視しても構いません。
プロセスBIPと呼ばれる、ビットコイン以外の部分を述べるBIP。プロセスBIPはスタンダードトラックBIPのように、コードの変更やビットコイン本体の変更を含めません。プロセスBIPは、主にコミュニティの同意を必ず必要とします。ユーザーは基本的にこれを無視してはいけません。ビットコインの手続きや説明、意見の決定方式、ビットコインの開発環境の変更などを決めます。メタBIPとも呼ばれます。

BIPの提案の流れ（ワークフロー）

BIPは、ビットコインに関するアイデアから始まります。BIPには、「チャンピオン」と呼ばれる、BIPを実際に文章にしたり、フォーラムで先頭に立って議論したり、コミュニティの同意を得たりする人物が必要になります。BIPの作者とも呼ばれます。チャンピオンはまず最初に、そのアイデアがBIPになるかどうかを確かめる必要があります。たとえば、 bitcoin-dev@lists.linuxfoundation.org というメーリングリストがあるのでそこに投げてみるのが一番いい選択肢だと思います。

BIPを書き始める前にアイデアを公開してもらうことで、他のアイデアとかぶるのを避けたり、またコミュニティの時間を節約することができます。
今まで、たくさんのアイデアが、さまざなま理由により、ビットコインに適用することを却下され、繰り越されてきました。
自分のアイデアを、まずコミュニティで聞くことで、そのアイデアが既に議論され却下されたことに気づかず、時間を無駄にするのを防ぐことができます。調べるだけじゃ出てこない議論があったかもしれません。
また、アイデアを公開することで、自分以外の人にアイデアを確認してもらえます。もし自分がそのアイデアが良いと思っても、他のユーザーもそう思うとは限らないからです。
小規模な機能追加やパッチなどは、BIPを必要としません。ビットコイン本体のワークフローに適切にパッチを提出してください。

チャンピオンは、アイデアが受け入れられるかどうかをコミュニティに聞いたら、次にBIPの下書きをビットコイン開発者メーリングリストに投げるべきです。
これにより、文書の形式が正しいかどうかや内容の質はどうか、追記するべきかなど、下書きを改善するための意見を得ることができます。
議論によって、色々な提案が、BIPの下書きとともに bitcoin-dev メーリングリストに送られてきます。

下書きは、あとで示すように、BIPの書式で書かれていなければいけません。そうでないと、そもそも書式が正しくなるまで送り返されてしまいます。

BIP作者は、BIPの本番提出をする前に、コミュニティの意見を集める責任があります。しかし、議論が長く続いていると忘れられることがあります。なので、たとえば新しくメーリングリストを作ったり、他のBIP作者に個人的に意見を求めたり、Wikiやgitリポジトリを作るなど、作戦をねらないといけません。ここは特に慎重にするべきです。

1つのBIPには、1つの提案のみが含まれていることを強く推奨します。そうしないとBIPの内容に集中できません。もし1つでないと思ったら、複数のBIPに分けてみるのもいいでしょう。

BIP編集者は、BIPに状態や番号を割り当てます。あとに書いてあるBIP編集者に、BIPと関連するものをメールしてください。
また興味があれば、BIP編集者の責任と作業の流れを見てみると良いでしょう。
BIP編集者は、内容がぶれていたり幅が広すぎたりするBIPを拒否する権利を持っています。

BIP作者は自分でBIP番号を付けてはいけません。しかし、BIPの説明に、自分の名前やニックネームをつけるべきです。

BIP編集者がBIPを認めた場合、BIP番号が付けられ、スタンダードトラックBIPかインフォメーションBIPかプロセスBIPかを決められ、状態欄には「草案(Draft)」と付けられ、最後にgitリポジトリに追加されます。
BIP編集者は不当にBIPを拒否したりはしません。拒否する理由としては、内容が重複していたり、書式があっていなかったり、内容がぶれていたり、幅が広すぎたり、技術的に不可能だったり、適切な動機がなかったり、互換性がなかったり、ビットコインの哲学が保たれていなかったときなどがあります。
BIPが承認されるためには、最低限の条件があります。それはその提案がもたらす効果について、完結で完全な説明が書いてあることです。
また、なにかしらの改善をするものでないといけません。提案を実現するには、内容がしっかりとしていて複雑ではない必要があります。

BIP作者は必要に応じてgitリポジトリの草案を更新します。BIP編集者にプルリクエストを出せば取り込まれます。

スタンダードトラックBIPは、主に2つの章から成り立ちます。設計と参考実装です。BIPを勉強している人の支援になったりする場合を覗いて、参考実装をする前にBIPが承認されている必要があります。スタンダードトラックBIPは、最終的には実装にコード例やパッチ、URLなどを含んでいないといけません。

一度BIPが承認されるために、参考実装は完成していなければいけません。参考実装が完成し、コミュニティに受け入れられたら、状態は「最終段階(Final)」となります。

また、BIPは、「くりこし(Deferred)」状態になることもあります。BIP編集者は、BIPが長い間進捗がない場合などにこれを適用します。一度くりこしになったBIPは、BIP編集者が「草案(Draft)」状態に戻すことができます。

また、BIPは「拒否(Rejected)」状態になることもあります。全てに置いてアイデアではなかったときです。このように拒否状態を記録として残しておくことも重要なことです。

また、BIPが古くなってきたときは違うBIPに置き換えられることもあります。これはインフォメーションBIPなどでAPIが新しくなった場合などに想定されています。

BIPの状態の変化図は以下のようになります。

このBIPのように、決して完成しないという意味で、変更の余地があると判断されるBIPなど、いくつかのインフォメーションBIPとプロセスBIPは「有効(Active)」状態になります。

今まで承認されたBIPに共通する特徴

それぞれのBIPが、以下のようなことに従っていました。

前文 -- BIPに関する情報、簡単に理解できるタイトル(44文字まで)、名前、他の作者などを含むRFC 822の書式。
要旨 -- 技術的な問題を解決、改善する200文字以内の説明。
著作権表示/パブリックドメイン -- それぞれのBIPは、どのようなライセンスを持つか、またはパブリックドメインにするかどうかを明示的に示す必要があります。
仕様 -- 新しい機能に関する、技術的な構造や意味を説明します。仕様は、競合しているものなども含め、現在の使われているすべてのビットコインソフトにおいて、きちんと実装できるくらい詳しく書いてある必要があります。(Satoshiクライアント、BitcoinJ、bitcoin-js、libbitcoinなど)
動機 -- 動機には、なぜビットコインのプロトコルを変えたいかを示します。動機は、BIPが解決する、現在のプロトコルの不備や問題を、完結に示さなければいけません。動機が書いていないBIPは、あっさりと却下されます。
根拠 -- 根拠は、設計や、なぜそのような設計になったかという根拠を示し、仕様を肉付けするところです。根拠は、設計を考える上で出てきた他の案や関連した案なども付け加えるべきです。また、議論する上で出た懸念や反対案、コミュニティの総意なども証拠とともに説明する必要があります。
後方互換 -- 後方互換を持たないBIPは、必ずその旨や後方互換を保つ難しさを説明する必要があります。どのように後方互換が無いのか、またそれについてどのように対処すればいいかの提案などを、説明する必要もあります。後方互換を持たないのに十分な説明がなされていない場合でBIPが提出されると、あっさりと却下されます。
参考実証 -- 参考実験・実証は、BIPが最終段階(Final)になるまでに完成していなければいけません。BIPが承認されるまでは必要ありません。実際に参考とするコードを書く前に、まず仕様と根拠の完成、コミュニティの合意を得ることなどを先にするほうが良いでしょう。最終的な参考実装は、実験的なコードやビットコインのプロトコルに関する説明などを含む必要があります。

BIPのフォーマットとテンプレート

BIPは、mediawiki構文かmarkdown構文で書く必要があります。

BIPのヘッダーの構成

BIPは、RFC 822の通りのヘッダーから始まる必要があります。ヘッダーは以下のような構成にしてください。*がついている行に関しては説明があります。また、以下ヘッダーの行はすべて必須です。

  BIP: <BIP番号>
  Title: <BIPタイトル>
  Author: <作者の実名のリスト。メールアドレスはあってもなくてもいい。>
* Discussions-To: <メールアドレス>
  Status: <草案(Draft) | 有効(Active) | 承認(Accepted) | 繰越(Deferred) |
    却下(Rejected) | 差し戻し(Withdrawn) | 最終段階(Final) | 停止(Superseded)>
  Type: <スタンダードトラック(Standards Track) | インフォメーショナル(Informational) | プロセス(Process)>
  Created: <ISO 8601 (yyyy-mm-dd)書式の作成年月日>
* Post-History: <ビットコインメーリングリストに投稿された日付>
* Replaces: <BIP番号>
* Superseded-By: <BIP番号>
* Resolution: <URL>

Autherは、BIPの作者すべての実名を書きます。メールアドレスは書いても書かなくても良いです。例として、以下のようになります。

メールアドレスを含む場合

  Random J. User <address@dom.ain>

含まない場合

  Random J. User

もしたくさんの作者がいる場合、RFC 2822に従って別に分ける必要があります。

ResolutionヘッダーはスタンダードトラックBIPのみ必須です。これは、BIPが作られたことを宣言するWebページやメールの文章を指定する必要があります。

BIPが非公開な議論をされている間(草案(Draft)状態の場合など)は、Discussions-Toヘッダーはメーリングリストか、議論されているWebページのURLを指定します。議論がまだ作者だけの場合や、ビットコインメーリングリストで議論されている場合はこのヘッダーは不要です。

TypeヘッダーはBIPの種類を指定します。(スタンダードトラックBIP、インフォメーショナルBIP、プロセスBIP)

Createdヘッダーは、BIPにBIP番号が付けられた日にちを記録します。まだメーリングリスト段階の場合はPost-Historyにメーリングリストへ投稿された日にちを記録します。両ヘッダーはともに年-月-日の書式で書く必要があります。例: 2001-08-14.

Requiredヘッダーは、BIPが他のBIPに依存する場合に、依存する別のBIPの番号を示すために付けられます。

Superseded-Byヘッダーは、古いBIPをあとから置き換えるときに追加されます。置き換えたいBIP番号を指定します。新しい方のBIPがこのヘッダーで古いBIPを示す必要があります。

補助ファイル

BIPは、画像・図など、別のファイルを含むことがあります。画像は、BIP用のサブディレクトリの中に入れる必要があります。補助ファイルは、BIP-XXXX-Y.(拡張子)の形式にします。XXXXがBIP番号、Yは補助ファイルの通し番号です。

BIPオーナーの変更

たまに、BIPオーナーを新しいチャンピオンに変更することがあります。通常は、最初の方のオーナーを作者として残して起きますが、これは最初方のオーナー次第です。
オーナーを変更する良い理由としては、時間がない、管理する興味がなくなった、ネットに出てこなくなった(メールが音信不通とか)などが挙げられます。悪い理由としては、BIPの方向性に賛成できなくなったなどです。私達はみんなで合意できるように努力しますが、可能ではありません、そんなときは競合するBIPを出しても構いません。

もし、BIPオーナーの変更に興味があるなら、BIP編集者とBIPの作者に聞きましょう。いつまでもBIP作者から返信が無い場合は、BIP編集者が一方的に決定を下します。（一方的に判断を下すのは、作者から返信がない場合のみで、BIP作者の意見があるときにそれを覆したりなどは決してしませんよ。)

BIP編集者

現在のBIP編集者はLuke Dashjrだけです。luke_bipeditor@dashjr.orgから連絡をとれます。

BIP編集者の義務と作業工程

BIP編集者は、ビットコイン開発者メーリングリストに登録しています。BIPに関する全ての対応はluke_bipeditor@dashjr.orgに送ってください。

新しいBIPは、BIP編集者が以下の対応をします。

BIPを読み、完成しているかどうかを確認します。アイデアは技術的であり、そして却下される理由が無い必要があります。タイトルは内容を完結に表現している必要があります。
BIPの文章を編集します。誤字、脱字、文法の間違い、意味の間違いなどです。
BIPが完成していなかった場合（不備があった場合）、BIP編集者はBIP作者に対して修正すべき部分などと共に訂正を要求します。
一度BIPが完成すると、BIPのプルリクエストがリポジトリの開かれ、さらにそこで修正や意見が求められます。

BIP編集者が行うことは以下です。

BIPにBIP番号を割り当てます。特殊な場合を除き、現在有効なBIPナンバーの次の数を割り当てます）
BIPが完成し、十分に精査されたと思ったら、プルリクエストをマージします。
README.mediawikiのBIPの一覧に新しく行を追加します。
ビットコイン開発者メーリングリストで、BIP作者に対し、次にやるべきことを送信します。

BIP編集者は管理能力があり、また編集能力が求められます。
BIP編集者は、BIPの更新のたびに、誤字脱字、文法、その他文の間違えを確認しなければいけません。

履歴

この文章はPythonのPEP-0001から派生しました。殆どの部分はコピーされています。PEP-0001はBarry Warsaw, Jeremy Hylton, and David Goodgerによって書かれましたが、彼らにBitcoin Improvement Proposalに関する責任は一切ありません。またBIPやビットコインに関する質問を彼らにすべきではありません。そのような場合は、すべてビットコイン開発者メーリングリストに送信してください。

変更履歴

10 Oct 2015 - Added clarifications about submission process and BIP number assignment.

訳: BIP番号の割り当てに関する部分の解釈を明確にした。

01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.

訳: BIPチャンピオンについてと、コミュニティへの意見の求め方などを明確にした。

BIP 0001【翻訳】