BIP 1 — BIP の目的とガイドライン - ビットコイン・インスティテュート

  BIP: 1
  Title: BIP Purpose and Guidelines
  Authors: Amir Taaki <genjix@riseup.net>
  Status: Closed
  Type: Process
  Assigned: 2011-09-19
  Proposed-Replacement: 2

BIP とは何か

BIP は Bitcoin Improvement Proposal の略。BIP は、ビットコインコミュニティに情報を提供する設計文書、あるいはビットコインまたはそのプロセス・環境への新機能を記述する設計文書である。BIP は対象機能の簡潔な技術仕様と、その機能の根拠を提示するべきである。

BIP は、新機能の提案、課題に対するコミュニティ意見の収集、ビットコインに反映された設計判断の文書化のための主要メカニズムとして意図されている。BIP の著者は、コミュニティ内での合意形成と反対意見の文書化に責任を持つ。

BIP はバージョン管理されたリポジトリ上のテキストファイルとして保守されるため、その改版履歴自体が当該機能提案の歴史的記録となる。

BIP の種類

BIP には三種類ある:

スタンダードトラック (Standards Track) BIP は、ほとんどまたはすべてのビットコイン実装に影響する変更 (ネットワークプロトコルの変更、ブロックまたはトランザクションの妥当性ルールの変更、ビットコインを使用するアプリケーションの相互運用性に影響する変更や追加など) を記述する。
情報提供 (Informational) BIP は、ビットコインの設計上の論点を記述するか、ビットコインコミュニティへの一般的なガイドラインや情報を提供するが、新機能を提案するものではない。情報提供 BIP は必ずしもビットコインコミュニティの合意や推奨を表すものではないため、利用者と実装者は情報提供 BIP を無視することも、その助言に従うことも自由である。
プロセス (Process) BIP は、ビットコインを取り巻くプロセスを記述するか、プロセスへの変更 (またはプロセス内での出来事) を提案する。プロセス BIP はスタンダードトラック BIP に似ているが、ビットコインプロトコル本体以外の領域に適用される。実装を提案することはあるが、ビットコインのコードベースに対するものではない。多くの場合コミュニティの合意を要する。情報提供 BIP と異なり、プロセス BIP は単なる推奨を超えた拘束力を持ち、利用者は通常これを無視できない。例として、手続き、ガイドライン、意思決定プロセスの変更、ビットコイン開発で使われるツールや環境の変更などがある。メタ BIP もすべてプロセス BIP に分類される。

BIP のワークフロー

BIP プロセスは、ビットコインに関する新しいアイデアから始まる。各 BIP 候補にはチャンピオンが必要だ — 後述のスタイルと書式で BIP を書き、適切なフォーラムで議論を導き、当該アイデアを巡るコミュニティ合意の構築を試みる人物である。BIP のチャンピオン (別名: 著者) は、まずそのアイデアが BIP に値するかを確認する。確認には bitcoin-dev@lists.linuxfoundation.org (https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) メーリングリスト (および場合によっては Development & Technical Discussion (https://bitcointalk.org/index.php?board=6.0) フォーラム) への投稿が最善の手段である。

BIP を書くところまで進む前にアイデアを公の場で検証することは、潜在的な著者と広いコミュニティの双方の時間を節約することを意図している。これまで提示されたビットコイン変更案には、さまざまな理由で却下されたものが多い。アイデアが既出かどうかをまずビットコインコミュニティに問うことは、過去の議論で却下が確定しているものに無駄な時間が費やされるのを防ぐのに役立つ (ネット検索だけでは必ずしも十分ではない) 。さらに、アイデアが著者個人ではなくコミュニティ全体に適用可能であることを確認するのにも役立つ。著者にとって良く思えるアイデアでも、ビットコインが用いられる多くの地域でほとんどの利用者にとって機能するとは限らない。複数プロジェクトをまたぐ標準化を必要としない小さな改善やパッチは、BIP を必要とせず、対応するビットコインの課題追跡に対するパッチ提出として、関連するビットコイン開発のワークフローに投入されるべきである。

チャンピオンがアイデアの受容可能性についてビットコインコミュニティに問い合わせた後、ドラフトの BIP を bitcoin-dev (https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) メーリングリストに提示するべきである。これにより、著者はドラフト BIP を整え、適切な書式・高い品質に仕上げ、提案に関する追加の懸念に対応する機会を得る。議論の後、ドラフト BIP を bitcoin-dev リストと BIP エディターに送付する。このドラフトは後述する BIP スタイルで書かれていなければならず、それに反する場合、適切な書式ルールに従うまでさらなる検討は行われない。

BIP の著者は、提出前に当初のアイデアと BIP の双方についてコミュニティの意見を集める責任を負う。ただし、可能な限り、公開メーリングリスト上での長く拡散した議論は避けるべきである。議論を効率的に進める方策としては、当該テーマ専用の SIG メーリングリストを設ける、初期設計段階で著者が私的なコメントを受け付ける、Wiki ページや Git リポジトリを立てる、などがある。BIP の著者はこれらを状況に応じて使い分けるべきである。

単一の BIP には単一の主要な提案または新しいアイデアのみを含めることが強く推奨される。BIP は焦点が絞られているほど成功する傾向にある。迷う場合は、BIP を複数のよく絞り込まれたものに分割せよ。

BIP 番号の割り当てとステータスの変更は BIP エディターが行う。BIP 関連のメールはすべて、後述「BIP エディター」節に記載のエディター宛に送付すること。BIP エディターは、BIP の提案が焦点不足または広すぎると判断した場合、これを却下する権限を持つ。

著者は BIP 番号を自己割当してはならない。代わりに、著者の名前/ハンドルと BIP の主題を含むエイリアス (例: 「bip-johndoe-infinitebitcoins」 ) を用いるべきである。

BIP エディターが承認すると、エディターは BIP 番号を割り当て、スタンダードトラック・情報提供・プロセスのいずれかに分類し、ステータス「Draft」を付与し、BIPs git リポジトリに追加する。BIP エディターが BIP を不当に拒絶することはない。BIP ステータスを拒否する理由には、作業の重複、書式ルールの無視、焦点不足または広すぎ、技術的に不健全、十分な動機付けや後方互換性への配慮を欠く、ビットコイン哲学に反する、などがある。BIP が受理されるためには、最低限の基準を満たさなければならない。提案する強化策の明快かつ完全な記述であること。当該強化策が純然たる改善を表すものであること。当てはまる場合、提案する実装は堅実で、プロトコルを過度に複雑化しないこと。

BIP の著者は、git リポジトリ内でドラフトを必要に応じて更新できる。ドラフトの更新は、著者がプルリクエストとして提出することもできる。

スタンダードトラック BIP は二つの部分 — 設計文書と参照実装 — から構成される。BIP は、参照実装を始める前にレビュー・受理されているべきである。ただし、参照実装が BIP の理解を助ける場合はその限りではない。スタンダードトラック BIP は、コード、パッチ、または同等のものへの URL の形で実装を含めなければ「Final」と認められない。

BIP が受理された後、参照実装を完成させる必要がある。参照実装が完成しコミュニティに受理された時点で、ステータスは「Final」に変更される。

BIP には「Deferred」のステータスを付与することもできる。BIP の著者またはエディターは、BIP に進展がないときにこのステータスを付与できる。Deferred とされた BIP は、BIP エディターが Draft ステータスに戻すことができる。

BIP は「Rejected」となることもある。すべて検討した結果、良いアイデアではなかったということもある。それでも、その事実を記録に残すことは重要である。

BIP は別の BIP によって置換 (supersede) されることもあり、その場合、原 BIP は陳腐化する。これは情報提供 BIP において、API のバージョン 2 がバージョン 1 を置換する場合などを意図している。

情報提供 BIP やプロセス BIP の中には、完了が想定されないために「Active」のステータスを持つものもある。例えば BIP 1 (本 BIP) がそれに当たる。

成功する BIP に何が含まれるべきか

各 BIP は以下の部分を持つべきである:

前文 (Preamble) — BIP 番号、短い記述的タイトル (最大 44 文字)、各著者の名前と任意で連絡先情報など、BIP に関するメタデータを含む RFC 822 形式のヘッダー。
アブストラクト (Abstract) — 取り上げる技術的論点の短い (約 200 語) 説明。
著作権/パブリックドメイン (Copyright/public domain) — 各 BIP は、明示的にパブリックドメインに置かれている (本 BIP がその例) か、Open Publication License の下でライセンスされている必要がある。
仕様 (Specification) — 技術仕様は、新機能の構文と意味を記述するべきである。仕様は、現行のビットコインプラットフォーム (Satoshi、BitcoinJ、bitcoin-js、libbitcoin) のいずれにおいても、競合的かつ相互運用可能な実装を可能にするのに十分な詳細を備えるべきである。
動機 (Motivation) — ビットコインプロトコルを変更しようとする BIP において、動機は決定的に重要である。BIP が解決する問題に対して、既存のプロトコル仕様が不十分である理由を明確に説明するべきである。十分な動機を欠く BIP の提出は、その時点で却下されることがある。
根拠 (Rationale) — 根拠は、設計を動機付けたものと、なぜ特定の設計判断がなされたかを記述することで、仕様を肉付けする。検討された代替設計や、関連する作業 (例えば他言語での同機能の支持のされ方) を記述するべきである。

根拠は、コミュニティ内の合意の証拠を提示し、議論中に提起された重要な反対意見や懸念に触れるべきである。
後方互換性 (Backwards Compatibility) — 後方非互換性を導入する BIP は、それらの非互換性とその深刻度を記述する節を含めなければならない。BIP は、著者がこれらの非互換性にどう対処するつもりかを説明しなければならない。十分な後方互換性に関する論考を欠く BIP の提出は、その時点で却下されることがある。
参照実装 (Reference Implementation) — 参照実装は、BIP が「Final」とされる前に完成していなければならない。ただし、BIP が受理される前に完成している必要はない。仕様と根拠を先に固め、それに対する合意を得てからコードを書く方が良い。

最終実装には、ビットコインプロトコルに適したテストコードと文書を含めなければならない。

BIP の書式とテンプレート

BIP は mediawiki または markdown 形式で書かれるべきである。

BIP ヘッダー前文

各 BIP は RFC 822 形式のヘッダー前文で始めなければならない。ヘッダーは以下の順序で出現しなければならない。「*」の付いたヘッダーは任意で、後述する。それ以外のヘッダーはすべて必須である。

  BIP: <BIP number>
  Title: <BIP title>
  Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
  Status: <Draft | Active | Accepted | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  Type: <Standards Track | Informational | Process>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
* Post-History: <dates of postings to bitcoin mailing list>
* Replaces: <BIP number>
* Superseded-By: <BIP number>
* Resolution: <url>

Author ヘッダーは、BIP のすべての著者/所有者の名前と、任意でメールアドレスを列挙する。Author ヘッダーの値の形式は次の通りでなければならない。

Random J. User <address@dom.ain>

メールアドレスを含める場合はこの形式、含めない場合は単に

Random J. User

とする。

著者が複数いる場合は、それぞれを RFC 2822 の継続行規約に従って別々の行に置くべきである。

注: Resolution ヘッダーはスタンダードトラック BIP に対してのみ必須である。BIP に関する正式な裁定がなされたメールメッセージや他のウェブリソースを指す URL を含む。

BIP が私的な議論段階 (通常は初期 Draft 段階) にある間は、Discussions-To ヘッダーが BIP の議論場所のメーリングリストや URL を示す。BIP が著者と私的に、またはビットコインメーリングリスト上で議論されている場合、Discussions-To ヘッダーは不要である。

Type ヘッダーは BIP の種類 (スタンダードトラック・情報提供・プロセス) を指定する。

Created ヘッダーは BIP に番号が割り当てられた日付を記録し、Post-History は BIP の新しい版がビットコインメーリングリストに投稿された日付を記録する。両ヘッダーとも yyyy-mm-dd 形式 (例: 2001-08-14) であるべきである。

BIP は、当該 BIP が依存する BIP 番号を示す Requires ヘッダーを持つことがある。

BIP は、当該文書を陳腐化させた後の文書の番号を値とする Superseded-By ヘッダーを持つこともあり、その場合、新しい BIP は陳腐化させた BIP の番号を含む Replaces ヘッダーを持たなければならない。

補助ファイル

BIP は図表などの補助ファイルを含むことがある。画像ファイルは当該 BIP のサブディレクトリに含めるべきである。補助ファイルは BIP-XXXX-Y.ext と命名しなければならない。「XXXX」は BIP 番号、「Y」は通し番号 (1 から開始) 、「ext」は実際のファイル拡張子 (例えば「png」 ) で置き換える。

BIP のオーナーシップ移転

BIP のオーナーシップを新しいチャンピオンに移すことが必要になる場合がある。一般に、原著者を移転後の BIP の共著者として残すのが望ましいが、これは原著者次第である。オーナーシップ移転の正当な理由には、原著者がもはや BIP を更新する時間や関心を持たない、BIP プロセスを最後までやり遂げる気がない、ネットの「向こう側に落ちた」 (連絡が取れない・メールに応答しない) 、などがある。妥当でない理由は、BIP の方向性に同意しないというものである。BIP に対する合意形成を試みるが、それが不可能なら、いつでも競合する BIP を提出することができる。

BIP のオーナーシップを引き継ぐことに関心がある場合は、引き継ぎを希望するメッセージを原著者と BIP エディターの双方に宛てて送る。原著者がメールに適時に応答しない場合、BIP エディターが一方的な判断を下す (そうした判断はくつがえせないわけでもない :) ) 。

BIP エディター

現在の BIP エディターはルーク・ダッシュジュニアであり、luke_bipeditor@dashjr.org で連絡できる。

BIP エディターの責任とワークフロー

BIP エディターはビットコイン開発メーリングリストを購読する。BIP に関するすべての通信は luke_bipeditor@dashjr.org に送付 (または CC) されるべきである。

新しい BIP が来た場合、エディターは以下を行う:

BIP を読み、準備が整っているか (健全かつ完全か) を確認する。アイデアは、たとえ受理の見込みが低くとも、技術的に意味をなしていなければならない。
タイトルが内容を正確に表現しているか。
言語 (綴り、文法、文構造など) 、マークアップ (reST BIP の場合) 、コードスタイル (例は BIP 8 と BIP 7 に合わせる) について BIP を編集する。

BIP の準備が整っていない場合、エディターは具体的な指示と共に著者に差し戻す。

BIP がリポジトリ用に整ったら、GitHub 上の bitcoin/bips (https://github.com/bitcoin/bips) リポジトリに「プルリクエスト」として提出されるべきであり、そこでさらに意見を集めることもある。

BIP エディターは以下を行う:

プルリクエストのコメントで BIP 番号 (ほぼ常に次の利用可能な番号、ただし時には 666 や 3141 のような特別/冗談の番号) を割り当てる。
著者の準備が整い次第 (さらなるピアレビューの時間を取った上で) プルリクエストをマージする。
README.mediawiki に BIP を載せる。
BIP の著者に次の手順 (bitcoin-dev メーリングリストへの投稿) を返信で伝える。

BIP エディターは管理および編集上の責任を果たすことを意図している。BIP エディターは BIP の変更を監視し、見つけた構造・文法・綴り・マークアップの誤りを訂正する。

沿革

本文書は Python の PEP-0001 から大きく派生している。多くの箇所で文章が単純にコピー・改変されている。PEP-0001 のテキストは Barry Warsaw、Jeremy Hylton、David Goodger によって書かれたが、彼らはビットコイン改善プロセスにおける本文書の利用について責任を負わず、ビットコインや BIP プロセスに固有の技術的な質問で煩わせるべきではない。すべてのコメントは BIP エディターまたはビットコイン開発メーリングリストに直接送付されたい。

変更履歴

10 Oct 2015 - 提出プロセスと BIP 番号割り当てに関する明確化を追加。

01 Jan 2016 - BIP のアイデア推進、コミュニティ意見の収集など、初期段階を明確化。

BIP 1 — BIP の目的とガイドライン