Compact Block Filters は各ブロックから決定論的に作る小さな確率的索引です。BIP 158 が内容と符号化、BIP 157 が配信と連続性検査を定め、クライアントは監視スクリプトを手元で照合します。
ウォレットはブロックとフィルターのヘッダーを同期し、フィルターを取得してスクリプトをローカルに検査します。一致時はブロック全体を取得して実際の取引を探します。一致だけで残高を増やしてはいけません。フィルターは金額、所有証明、全取引履歴を返しません。 [BIP 157 — Client Side Block Filtering]
BIP 158 basic は OP_RETURN で始まるもの以外の新規出力の scriptPubKey と、coinbase 以外の入力が使う過去出力のスクリプトを含みます。空の要素は省きます。アドレス文字列は正しいスクリプトに変換する必要があり、txid、witness データ、任意メモの万能索引ではありません。 [BIP 158 — Compact Block Filters for Light Clients] [Bitcoin Core — BasicFilterElements]
Golomb-Rice は整列したハッシュ値の差を符号化し、basic は P=19 と M=784931 を使います。非要素の問い合わせ一回が約 1/M で一致し得ます。監視スクリプトが増えるほど衝突の機会も増え、ウォレット全体の固定誤り率ではありません。正しく作られたフィルターは含む要素を見落としません。 [BIP 158 — Compact Block Filters for Light Clients]
フィルターヘッダーは現在のフィルターハッシュと前のヘッダーを結びます。連続性の検査は受け入れ済みチェーンとの差を検出しますが、そのコミットメントは Bitcoin ブロックヘッダーに入りません。攻撃者は内部整合した偽フィルターを作れます。ハッシュ計算が正しいだけでは内容の真実性を保証しません。 [BIP 157 — Client Side Block Filtering]
BIP 157 は少なくとも一つの正直な相手を含むピア比較で偽フィルターを検出します。basic の再構築には使用済み過去出力のスクリプトも必要になり得ます。再編成では新しい枝のフィルターを追い、ウォレット状態を計算し直します。同じ旧高度が同じブロックを表すとは限りません。 [BIP 157 — Client Side Block Filtering] [Bitcoin Core — BasicFilterElements]
BIP 37 と違い個人のアドレスフィルターをサーバーに送りません。しかしピアは IP、時刻、要求ブロックを観察し得ます。異なるピアからの取得は情報の集中を抑えますが、すべての相関を防ぎません。偶然の一致だけで通信が匿名になるわけではありません。 [BIP 157 — Client Side Block Filtering]
Bitcoin Core RPC getblockfilter は対応インデックスを有効にするとブロックハッシュに対するフィルターとヘッダーを返します。それだけでは公開 P2P サービスや全過去ブロックの提供能力を証明しません。クライアントには機能するブロック取得元が必要で、完成ブロックのフィルターは Mempool の未確認取引を知らせません。 [BIP 157 — Client Side Block Filtering] [Bitcoin Core 30.0 — getblockfilter]
BIP 152 の Compact Blocks は短い取引識別子とローカル Mempool で新規ブロックの伝送を速めます。Compact Block Filters はクライアントに関係するブロックを選びます。ローカル一致や取引の包含確認は、全ブロックの独立した完全なコンセンサス検証を代替しません。 [BIP 157 — Client Side Block Filtering] [BIP 152 — Compact Block Relay]
理解を深めるには、この項目とあわせて次もお読みください Compact Block Filters, Neutrino, Full Node, Bitcoin のプライバシー, Compact block relay. 次の項目からも参照されています Neutrino.