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のアイデア推進、コミュニティ意見の収集など、初期段階を明確化。