BIP-324暗号化トランスポート

BIP-324に対応した2つのノードは、Bitcoinのメッセージを1つも送信する前に一時的な鍵交換を行い、その後、すべてのメッセージをChaCha20Poly1305で包みます。仕様は2024年7月10日に最終版として確定し、ノードはサービスフラグNODE_P2P_V2、ビット11で対応を通知します。保有するビットコインに関する変化はありません。変わるのは、受動的な観測者がノードのやり取りするトランザクションを読めなくなることです。

仕組み

BIP-324は、かつてビットコインの接続を開始する際に使われていた固定のマジックバイトを、まったく認識可能な形状を持たないストリームに置き換えます。

接続を開始する側は使い捨てのsecp256k1鍵を生成し、自身の公開鍵の64バイトのElligatorSwiftエンコーディングを送信します。このエンコーディングが要点です。通常の公開鍵は曲線上の点として識別できますが、512ビットの文字列はどれも有効なElligatorSwiftエンコーディングであるため、冒頭のバイトは統計的には単なるノイズです。その後、どちらの側も最大4095バイトの任意のパディング（garbageと呼ばれます）を追加できるため、接続が必ず64バイトで始まる必要はありません。両端はX-only ECDHを実行し、その結果をHKDF-SHA256に通して、4つの暗号化鍵、2つの16バイトのgarbageターミネーター、セッションIDを導出します。

この冒頭のバイトだけが平文で送信される部分です。ターミネーターの後は、通信路上のすべてがパケットです。パケットは、3バイトの暗号化された長さフィールドに続いて、1バイトのヘッダーと内容を対象とするChaCha20Poly1305の暗号文であり、ペイロードに加えて20バイトを要します。そのヘッダーの最上位ビットは無視ビットであり、これを立てたパケットはデコイです。受信側は復号できることを確認してから破棄します。これにより、ノードは通信量をパディングして、実際のメッセージが送信された時点を偽装できます。鍵は224パケットごとに前方へラチェットされ、この間隔は、20分ごとのpingだけを送るほぼアイドル状態のリンクでもおよそ3.11日ごとに鍵が更新されるように選ばれています。このラチェットがセッションに前方秘匿性（forward secrecy）を与えます。

この設計は、相手が誰であるかを証明する手前で意図的に止まっています。証明書も身元情報もないため、執拗な中間者は依然として2つのノードの間に居座れます。しかし、低コストで居座ることも、不可視のまま居座ることもできません。セッションIDは鍵交換から得られるものであり、2人の運用者が互いの値を読み上げれば、誰かが間にいる場合は必ず異なる値になります。

どこで確認できるか

BIP-324はブロックチェーン上には何も残さないため、確認できるのは稼働中の2つのノードの間だけです。

対応は、ピアがaddrメッセージとaddrv2メッセージから知るNODE_P2P_V2フラグを通じて、アドレスのゴシップで通知されます。このフラグは信頼できないリレーを経由し、論理和で結合されるため、偽の通知が行われる可能性があります。また、このBIPは、直ちに切断されたv2クライアントに対して、同じピアへv1で再試行することを推奨しています。逆方向では、v2ノードはネットワークが互いに到達できない2つの半分に分裂するのを防ぐため、受信するv1接続を意図的に受け入れ続けます。

2つ目の目に見える効果はメッセージの短縮です。バージョン1は各コマンド名に12バイトのASCIIを使用していましたが、バージョン2はこれまでに定義された28種類のメッセージタイプに1バイトのIDを割り当てるため、invは1バイトの14、getblocktxnは10となり、短いIDを使うメッセージはv1形式より3バイト少なく済みます。IDが割り当てられていないものは、13バイトのエンコーディング、すなわちゼロバイトに続いて従来のASCII名を書き出す形式にフォールバックするため、失われるものはありません。

仕様のステータスはDeployed（デプロイ済み）であり、テストベクターと、デモンストレーションのみを目的とした素朴なPythonリファレンス実装が含まれ、現在も編集が続いています。2026年1月30日のリビジョン1.0.2では、他のBIPが本文を編集せずにIDを要求できるよう、補助ファイルにメッセージタイプIDの表が追加されました。また、ヘッダーには、BIP-324がBIP-151を置き換えることが記録されています。