Compact Block Filters

アンナはスマートフォンのウォレットで入金を待っています。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ブロックは取引をまとめたものですが、端末がすべてのブロックを丸ごと取得する必要はありません。本の索引から必要なページを探すように、先に小さなフィルターを調べられます。同じブロック、同じフィルター種別なら、誰もが受け取る要約は同じです。アンナに関係するかどうかの選別は端末内で行います。技術文書 BIP 157 はフィルターの取得と確認を、BIP 158 は内容と作り方を定めています。ウォレットはまず、ブロックを鎖状につなぐ基本情報であるブロックヘッダーを検証します。次にフィルターの確認用データとフィルター本体を取得し、一致すればブロック全体から実際の取引を探します。名前が似た BIP 152 の Compact Blocks は、新しいブロックをノード間で速く転送する別の仕組みです。ノードは、取引やブロックを検証し、ネットワークの他の参加者と通信するソフトウェアです。 [1] [2] [5] [6]

Bitcoin の取引は、金額と後で使うための条件を持つ「出力」を作ります。その条件を書くコードが scriptPubKey です。新しい取引の「入力」は、使おうとする過去の出力を指定します。識別子 0x00 の basic フィルターには、新しい出力のスクリプトと、そのブロックで使われる過去の出力のスクリプトが入ります。これによりアンナは受け取りと支出の両方を探せます。新しい出力のうち、支出不能にする命令 OP_RETURN で始まるスクリプトは除外されます。過去の出力を使わずに採掘者へ報酬を割り当てる coinbase 取引の特別な入力も除外されます。空の項目は省き、同じ項目は一度だけ数えます。すべての取引識別子 txid、アドレス文字列、署名などの witness データを集めた一覧ではありません。正しく作るには、新しいブロックだけでなく、その取引が使う過去の出力データも必要です。 [2]

サーバーがアンナの支払いだけを意図的に省いた要約を送る可能性があります。そのためウォレットは、フィルターと過去のフィルターとのつながりも確認します。ハッシュとはデータの短いデジタル指紋です。保存したフィルターに SHA-256 を二度適用すると double-SHA256 が得られます。それを前のフィルターヘッダーにつなげ、同じ方法でハッシュ化すると次のヘッダーになります。過去のフィルターを変えれば、それ以降の確認データも変わります。ただし、採掘で保護されるブロックヘッダーには、この補助的なフィルターの鎖のハッシュは含まれていません。すべての接続先が同じ偽の鎖を渡せば、指紋は矛盾なくつながり得ます。数学的に整合しているだけでは、要約が本物のブロックに対応するとは証明できません。 [1]

そこで BIP 157 は、独立した複数のノード、通信相手としての peers に接続するよう勧めています。自分のノードなど、信頼する相手との安全な接続も選択肢です。フィルターの鎖が食い違えば、ウォレットは最初の相違点を見つけ、そのブロックと必要な過去の出力から正しいフィルターを作り直せます。正しいフィルターを識別できるという保証は、少なくとも一つの正直なピアがいることを前提とします。同じ攻撃者への接続が複数あっても、この条件は満たしません。ブロックチェーン自体も変わります。再編時には末尾の一部が、累積した実証済みの計算作業量がより多い枝に置き換わります。ウォレットは新しい枝のフィルターを使い、影響を受ける支払いを確認し直す必要があります。一度見つかった承認も、どの鎖がネットワークに受け入れられるかに依存します。 [1] [2]

以前の BIP 37 では、ウォレットが監視したい内容のフィルターをサーバーへ送っていました。Compact Block Filters では逆に、共通データを受け取って自分の端末内で選別します。そのため監視するスクリプトの情報が漏れにくくなります。それでも提供者にはアンナが後からどのブロックを丸ごと要求したかが分かり、接続のネットワーク上の住所である IP アドレスと関連付けられる可能性があります。繰り返すアクセスから別の傾向も分かるかもしれません。BIP 157 は、ウォレット側から接続を開いたノードの中で、ブロック取得先をランダムに選ぶよう勧めます。ブロックとフィルターは別のノードから取得できます。プライバシーは改善しますが、匿名性を保証するものではありません。 [1]

フィルターが対象にするのは、すでに鎖に入ったブロックです。特定のノードが転送や採掘に備えて保持する未承認取引の集合、現在の Mempool は対象ではありません。一致しても、見つかった資金を使う鍵をアンナが持つ証明にはなりません。秘密鍵は、ウォレットが資金を使うことを承認するデジタル署名を作るための秘密の数値です。ウォレットは実際の取引と、そのブロックへの収録を確認する必要があります。それでも軽量クライアントは、Full Node のようにすべてのブロックの全取引を全ルールに照らして検証するわけではありません。省資源化には実際の安全性のトレードオフがあります。データの入手可能性も別の問題です。Pruned Node は検証後に古いブロックを消し、フィルターだけを残せます。その場合、アンナは要約を取得できても、ブロック全体は別の場所から入手しなければなりません。古いデータの削除だけで、ノードが完全なルール検証をやめるわけではありません。 [1] [5]

小さくする代わりに、探す項目がなくてもフィルターが「あるかもしれない」と答える場合があります。これが false positive、誤一致です。アンナは不要なブロックを取得しますが、実際の支払いが見つからなければウォレットは残高に加えてはいけません。正しいフィルターは、規則上そこに含まれる項目を見落としません。ただし、この性質は悪意あるサーバーの捏造データを正しくするものではありません。技術的には SipHash-2-4 で各項目を N × M の大きさの範囲内の数値に変換します。N は項目数です。数値を並べ替え、その差を Golomb-Rice 符号で小さく保存します。P=19 は符号化を調整し、M=784931 は偶然の一致に関係します。集合外の項目を一つ調べたときの誤一致確率は約 1/M です。バイトはデータ量を表す一般的な単位です。SipHash の鍵は、ブロックハッシュを little-endian、つまり下位バイトから並べたときの先頭 16 バイトです。ウォレットの秘密鍵ではありません。ここでの SipHash は項目をフィルター用の数値に変換するもので、暗号化するものではありません。保存データは、非負整数用の CompactSize 形式で表した N から始まります。 [2]

確認日 2026-10-17 時点で両文書の状態は Deployed です。プロトコルが運用されているという意味で、すべてのウォレットが対応するという意味ではありません。以下の設定例は Bitcoin Core 29.0 に限った説明です。-blockfilterindex はローカル索引を作り、他のノードへの提供には -peerblockfilters と basic 索引が必要です。NODE_COMPACT_FILTERS が対応を通知します。プログラム向けの RPC インターフェースでは、getblockfilter が指定ブロックの filter と header を返します。RPC が動くことだけでは、他のネットワークノードにフィルターを提供している証拠になりません。仕様書では getcfilters/cfilter がフィルター、getcfheaders/cfheaders が連結確認用データ、getcfcheckpt/cfcheckpt が補助的な鎖のチェックポイントを扱います。これらはネットワークメッセージの名前であり、スマートフォンの利用者が入力するコマンドではありません。 [3] [4]