あなたは「BIP」を書くべきだ ── bitcoin++ Sovereignty Edition（台北2025）
ここで非常に重要なポイントがあります。
BIP が存在するからといって、それを採用すべきだという意味ではありません。
(※中略：詳細は本編へ)
BIP 番号が付いているからといって、それをやるべきだと思ってはいけません。
世の中には “ダメな BIP” がたくさんあります。
もし本当に興味があるなら、いくつか例を指摘してあげます。
それに、まだ却下されていないけれど、
私個人として「これは却下すべきだ」と思っている BIP もあります。
こんにちは！yutaro です。
本日のPro向け「BTCインサイト」では、”BIP” という言葉は聞いたことがあるものの、実際に何を指すのかはよく分からない──そんな方に向けて、学びの多い動画を紹介します。
スピーカーは、これまでに18本のBIPを執筆し、歴代2位の本数を誇る Ava Chow 氏。
本講演では、「そもそもBIPとは何か？」という基本的な話から始まり、後半では 「どのようにBIPを書くべきか」 という実践的な視点にまで踏み込んで解説されています。
専門的な用語もいくつか登場しますが、BIPの役割や背景、そしてビットコイン開発における位置づけが立体的に理解できる、とても濃度の高い内容です。
少し長めの記事にはなりますが、ぜひ最後までお楽しみください。
イントロダクション：BIPとは何か？
Ava Chow氏：
私のトークタイトルは『あなたはBIPを書くべきだ』ですが、実際のところこれは、私が25分間ひたすらBIPについて rant（愚痴を言う／文句を言う）するだけの話です。
でも、私は本当に、皆さんはBIPを書くべきだと思っています。
過去10年間、私は Bitcoin Core Wallet に取り組んできました。その中で大量のBIPを読み、多くを実装し、そして自分自身でもかなりの数を書いてきました。実際、私は 18本のBIPを書いていて、これは Peter Wuille に次いで2番目に多い数です。彼は27本書いています。
まず最初に、そもそも BIP とは何なのか？
あの、何か実装したいとき、まずライブラリを探しますよね。誰かがすでにその作業をしてくれていないかどうかを確認するために。
もしライブラリが見つからない場合、誰かがその機能の設計や仕様、つまり“こうやってやるんだよ”という書類を書いていることがあります。
BIP というのは、まさにその「設計や仕様」のことです。
BIP は Bitcoin Improvement Proposal の略で、IETF の RFC や Python Enhancement Proposal（PEP）をモデルにしています。
そして、BIP は Bitcoin の通貨としてのユーティリティを支える、または拡張する技術を説明したり情報提供する文書群です。
つまり、この定義は驚くほど曖昧です。
Bitcoin に関連していて、言語化できるものなら何でも BIP になり得ます。
実際、そういう“なんでもあり”カテゴリーとして informational（情報提供）BIP という分類があります。
BIPの種類 ― Specification / Informational / Process
BIP には全部で 3つの種類 があります。
まず、最も一般的で、私自身が主に注目しているのが Specification BIP です。
これは、実装可能なものを記述するBIP です。
新しい概念でも、新機能でも、ある種の標準でも、本当にソフトウェアとして実装できるものであれば、何でも Specification BIP になり得ます。
たとえば、私たちのお気に入りのフォーク提案、ピアツーピアネットワークのメッセージ、Payjoin のような関連プロトコル、あるいはウォレットにしか関係しないもの──PSBT、ディスクリプタ、階層的導出（HD）、導出パスなどです。
これらはすべて Specification BIP に分類されます。
数は数百あり、BIPS リポジトリの中で 圧倒的多数 を占めています。
2つ目の種類は Informational BIP です。
これらは、実装できるものではありません。
Bitcoin に関して、人々が知っておきたい追加情報を提供するだけのものです。
たとえば、bits という単位の定義は Informational BIP です。
また、Satoshi（サトシ）を Bitcoin の基本単位として定義した Informational BIP もあります。
こうしたものは、すべて用語や定義に関するものです。
それから、2013年のチェーンフォークに関する 事後分析（ポストモーテム） も Informational BIP として存在しています。
なぜか、これがこの種のBIPとしては唯一の例です。
誰も他の出来事について事後分析を書いて、BIPとして提案しようとはしませんでした。
最後の種類が Process BIP です。
これは主に BIP 1、BIP 2、BIP 3 です。
これらは、そもそも BIP がどのように機能するのか を説明するものです。
現在使われているプロセスは BIP 2 です。
そして、将来的には BIP 3 に置き換えられる予定です。
BIP 3 は BIP 2 の改訂版です。
いくつか変更点はありますが、大きく変わったわけではありません。
プロセス自体はほぼ同じで、用語が少し変わった程度です。
ただし、全体としては かなり大きな改善 だと私は思っています。
BIPは「存在する＝採用すべき」ではない
ただし、ここで非常に重要なポイントがあります。
BIP が存在するからといって、それを採用すべきだという意味ではありません。
BIP が存在することは、
それが良いアイデアであること
誰かが支持していること
実装すべきであること
のどれも意味しません。
BIPS リポジトリを見れば、withdrawn（撤回） や rejected（却下） とラベル付けされた BIP が山ほどあります。
これらは、
書いた本人が、書いた後に「これは悪いアイデアだった」と気づいて撤回したもの
（こういうことは時々起こる）
もしくは、
コミュニティ全体が「これは悪いアイデアだ」と判断したもの
です。
だからこそ、これは本当に重要です。
BIP 番号が付いているからといって、それをやるべきだと思ってはいけません。
世の中には “ダメな BIP” がたくさんあります。
もし本当に興味があるなら、いくつか例を指摘してあげます。
それに、まだ却下されていないけれど、
私個人として「これは却下すべきだ」と思っている BIP もあります。
それについては後で議論できます。
何がBIPになるべきか ― 2つのカテゴリー
では、何がBIPになるべきなのか？
私は、Specification BIP には 2つの大きなカテゴリー があると思っています。
1つ目は、ソフトウェア同士が互換性を持つ必要があるもの です。
もっとも分かりやすい例はフォーク提案です。
同じコンセンサスルールを、複数の人がそれぞれ実装することになります。
そのとき、それらが互換である必要があります。
その互換性を可能にするのが、標準文書です。
これはフォーク提案だけでなく、
ピアツーピアネットワークメッセージ、
mempool ポリシー、
Payjoin、
つまり 異なるソフトウェア同士が通信する必要があるものすべて に当てはまります。
2つ目のカテゴリーは、誰か他の人にとっても役に立つかもしれない実装可能なもの です。
ここは特に、ウォレット開発に携わっている私たち全員に関係する部分だと思います。
自分たちにとってはとても良いアイデアで、実際にうまく動いている。
そして、将来、他の誰かもこれを使えるかもしれない。
そういう場合には、そのアイデアを共有し、この分野でのイノベーションを促進するために、BIPを書くことを検討すべきです。
良いアイデアは共有されて初めて価値を持つ
このカテゴリーの例としては、BIP 32 の HD ウォレット があります。
この話題は、今日も何度も出てきましたね。
他にも、PSBT や ディスクリプタ があります。
これらはすべて、役に立つものです。
これらは、単一のソフトウェアの中だけでも成立する、良いアイデアです。
しかし、それを他の人と共有することで、
互換性を生み出し、その上に新しいものを構築できるようになります。
だからこそ、こうしたものは BIP として書かれる価値があります。
BIPにすべきだったが、そうなっていないもの
残念ながら、この分野には、
実際にエコシステムで使われているにもかかわらず、BIP になっていないもの がたくさんあります。
そして、それらはおそらく BIP であるべきだったと思います。
ここで重要なのは、BIP は後から書くこともできる という点です。
つまり、
何かを作る → 良いアイデアだ → デプロイされる → 広く使われる
その後で、
『これは BIP にすべきだったな』
と気づいて BIP を書く、という流れも可能です。
実際、ディスクリプタ はそうでした。
最初は Bitcoin Core 専用の、ただのドキュメントだったと思います。
その後、多くの人がディスクリプタを使い始めました。
そして、約3年後に私は
『そろそろ BIP を書くべきだろう』
と思いました。
そうすれば、Bitcoin Core リポジトリにあるランダムな Markdown ファイルではなく、
正式で標準的な仕様 を持てるからです。
10年間「存在しなかった」BIP 48の話
もう一つの例は BIP 48 です。
ちょっと面白い話があります。
古いウォレットソフトのいくつかを見ると、
“BIP 48”
という謎の記述が出てきます。
BIP 48 は、マルチシグの導出パスを規定するもの、とされていました。
ところが──
その BIP 48 は、実際には約10年間存在していなかったのです。
私は以前、Trezor のファームウェアのリポジトリを調べていて、
“BIP 48”
という記述を見つけました。
そこで BIPS リポジトリを確認すると…
BIP 48 が存在しない。
『え、じゃあこれは一体何なんだ？』
となりました。
幸いなことに、数年前に誰かが、
各ウォレットが “BIP 48” と呼んでいたものをすべて調査し、
それらが実際に何を指していたのかを突き止め、ドキュメントとして書き起こした のです。
そのおかげで、今では正式な BIP 48 が存在します。
こういうことは、今後もまた起こり得ます。
本来はBIPであるべきだったもの（Electrum編）
ここから、特定の誰かを批判したいわけではありませんが、
このリストに共通するテーマがいくつかあります。
まず最初に挙げる notable な “non-BIPs（BIPではないがBIPであるべきもの）” は、
Electrum プロトコル です。
Electrum プロトコルとは、ライトクライアントが Electrum サーバーと通信するためのプロトコルです。
私の経験では、このプロトコルについてのドキュメントは本当にほとんど存在しません。
BIP ではないにも関わらず、非常に広く使われています。
特にモバイルウォレットの多くは Electrum クライアントを実装していますし、
Electrum サーバーの実装も 5〜10 程度存在します。
ところが、入手できるドキュメントは
特定の実装に紐づいていたり、実装ごとに微妙に仕様が違ったりする のです。
つまり、相互互換性が保証されていません。
もし誰かがこれをきちんと 正典（canonical）の標準仕様 として書いていたら、
私たちはこうした問題を抱えずに済んだはずです。
これは全員にとって有益だったでしょう。
Electrumシードフォーマット ― BIP39に反対するために作られたのにBIP化されなかった
次も Electrum 関連で、Electrum シードフレーズフォーマット です。
これは特にひどい例だと思っています。
Electrum のシードフレーズフォーマットは、
すでに存在していた BIP 39 に“反対するために”作られたものです。
つまり、既存の BIP に対抗する形で生まれたのに、
なぜ BIP として文書化しなかったのか？
理由は分かりません。
このフォーマットについてのドキュメントも、実質的に存在しません。
しかし、複数のウォレットがこのフォーマットを実装しています。
これはまさに BIP として書かれるべきケースです。
このリストに挙げるものすべてが、BIP の候補だと思いますし、
この中のどれについても、皆さんの誰かが BIP を書くことは可能です（アスタリスク付きですが）。
この “アスタリスク” については後で説明します。
Signed Message Format ― 事実上の標準だったのにBIPがない
次は Signed Message Format（署名メッセージ形式） です。
これは 2011 年ごろに Peter Wuille（ピーター・ウイーリ） が作ったフォーマットです。
これもまた非常に広く使われていました。
今日では以前ほど使われなくなっていますが、
当時は “鍵そのものを使う” という考え方が主流だったため、
多数のウォレットがこのフォーマットを実装していました。
ところが──
このフォーマットについての正式なドキュメントはゼロです。
私が見つけた“最も良いドキュメント”は、Peter が 2014 年ごろに書いた
Stack Exchange の投稿だけ でした。
このケースには一応、理由らしきものがあります。
この形式は public key recovery（公開鍵復元） を使っており、
これは特許技術だったため、
弁護士からの scrutiny（精査）を避けたかったのかもしれません。
とはいえ、これもまた BIP として書くべきものだったでしょう。
さらに悪いことに、この Signed Message Format は、
SegWit 登場前に作られたため、SegWit 非対応でした。
そこで SegWit が登場したとき、Electrum の開発者たちが勝手に
SegWit 版に拡張し、しかもその拡張をドキュメント化しなかった のです。
旧来のP2Pメッセージ ― 最も基本的なのにBIPがない
そして当然ですが、元々の P2P プロトコルメッセージ群 も同様です。
新しい P2P メッセージについては BIP が存在します。
新しいメッセージをどう使うか、どう実装するか、
いつ使うべきか、といった仕様を定義する BIP が複数あります。
しかし──
いまだに広く使われている“オリジナル”の P2P メッセージには、
その仕様を定義した BIP が一切ありません。
たとえば
versionメッセージaddrメッセージ
こうした基本的なものです。
もし Bitcoin の P2P ネットワークと通信するソフトウェアを書きたい場合、
“どう実装すべきなのか” を知るのが非常に難しい状態です。
現在、利用できる最良のドキュメントは
Dave Harding が約10年前に bitcoin.org に書いた説明 ですが、
BIPではありません。
ソフトウェアを実装する人にとって、これは大きな問題です。
Stratum ― 採掘を支えるのに、仕様が存在しないプロトコル
最後に挙げるのは Stratum です。
Stratum は、マイナーがマイニングプールと通信するためのプロトコル、あるいはその逆の通信に使われるプロトコルです。
これもまた、まったくと言っていいほどドキュメント化されていません。
私は Stratum に関するドキュメントを一切見つけることができませんでした。
Stratum は Electrum プロトコルをベースにしていますが、
実際にどう使うのか？
人々は現実にはどうやって Stratum v1 を使っているのか？
実情としては、
何年も前に書かれた CGMiner のコードをそのままコピー＆ペーストして、
あちこちで使い回しているだけです。
これは正直、あまり良い状況とは言えません。
ここでアスタリスクを付けている理由ですが、
Stratum については ついにドラフトBIPが存在する からです。
誰かがようやく BIPS リポジトリに PR を出し、
13年前に番号だけ割り当てられ、文書が存在しなかった Stratum のBIP を追加しようとしています。
実際、BIPS の README を見ると、
Stratum は BIP 40 と BIP 41 です。
これらは 2012 年ごろに番号が割り当てられましたが、
ドキュメントは一度も存在しませんでした。
これらはすべてBIPであるべきだった
以上が、間違いなく BIP が存在すべきだったもの の例です。
もし皆さんの誰かが BIP を書いてみたいと思うなら、
それについていくつか意見があります。
では次に、
『BIPを書くにはどうすればいいのか？』
について話しましょう。
BIPを書くにはどうすればいいのか（プロセスの前提）
BIPを書くにはどうすればいいのか？
DH Magazine Proへの招待
月7ドルでDH Magazine Proに参加して、より詳細な情報を受け取りつつ、Diamond Handsの活動を支援しよう！
詳細は以下のPro版の内容紹介記事をご確認ください。
