用語集 / 開発者向けリファレンス
MSG_FILTERED_WITNESS_BLOCK
- MSG_FILTERED_WITNESS_BLOCKとは？
- フィルタ済みウィットネスブロック型はBIP144の予約リストとBitcoin Coreのソースのenumに存在しますが、どちらにも実装はありません。
BIP-144で規定されています。
MSG_FILTERED_WITNESS_BLOCKはインベントリコード0x40000003で、2016年にsegwitのピアルールが書かれた際に予約され、実装が与えられることはありませんでした。Bitcoin Coreはそれをenumの項目として保持しており、コメントがまさにそのことを記録しています。これが拡張するはずだったライトウォレット機能、BIP37のブルームフィルタリングは、Bitcoin Core 0.19.0でデフォルトで無効化されました。これは、お使いのスマートフォンのウォレットが今もそれに頼っている場合にのみ関係します。
仕組み
状態：予約済みで、実装されたことはありません。BIP144がこの型に名前を付け、Bitcoin Coreはsrc/protocol.hのenum項目としてそれを保持しており、コメントがハンドラが存在しないことを記録しています。これが提供するはずだったBIP37のフィルタリングは、2019年11月のBitcoin Core 0.19.0以降デフォルトで無効化されており、BIP157とBIP158のコンパクトブロックフィルタがその代替です。
この空白を理解するには、フィルタ済みブロックとは何だったのかを理解する必要があります。BIP37を使用するライトクライアントは、関心のあるアドレスを大まかに記述したfilterloadメッセージを送信します。次にインベントリ型3、MSG_FILTERED_BLOCKを要求し、応答するノードはmerkleblockメッセージで返信します。これは80バイトのブロックヘッダ、トランザクション数、部分マークルブランチ、そしてツリーをどちらの方向にたどるかを示すビットフィールドです。一致するトランザクションは別々のメッセージとして続きます。クライアントは、それぞれが本当にヘッダのマークルルートから派生していることを確認し、それはtxidのみを使って行われます。
ウィットネスはその計算に一切関与しませんでした。マークルルートはtxidから構築されるため、ライトクライアントは署名なしで包含を証明でき、続くトランザクションはウィットネスを取り除いて送信されました。ウィットネスフラグを追加した予約型3、0x40000003は、クライアントがそれらのトランザクションを完全な形で要求できるようにしたはずです。誰も実装しませんでした。ライトウォレットを作る誰も、より多くのBIP37を望まなかったからです。
その理由は労力ではなくプライバシーです。クライアントがアップロードするフィルタは、どのアドレスが自分に属するかを大まかにノードに伝え、2010年代半ばまでの研究は、それらのフィルタが意図したよりはるかに多くを漏らすことを示しました。Bitcoin Coreの答えは、設計を修復するのではなく、デフォルトでそれらを提供するのをやめることでした。BIP158はむしろ流れを逆にします。ノードはブロックごとに1つの小さなGolomb符号化フィルタを構築し、784,931分の1の偽陽性率に調整して公開します。クライアントはフィルタをダウンロードし、ローカルでテストし、ヒットした場合にのみブロック全体を取得するため、サーバーはどのアドレスが関心の対象だったかを一切知りません。
どこで見かけるか
ほとんどどこでも見かけません。参照表でMSG_FILTERED_WITNESS_BLOCKを見つけた人にとって、それが正直な答えです。
Bitcoin Coreでこの定数をgrepすると、enumの項目が1つ見つかります。btcdのような代替実装は、完全性のためにワイヤパッケージで同じ名前を反映していますが、ここでもその背後に動作はありません。どのウォレットもこれを送信したことはありません。
この話題が購入者に関わるのは、モバイルウォレットがどのようにデータを取得するかという点です。ウォレットが自身をSPVと称し、ブルームフィルタを使ってランダムな公開ノードに接続する場合、それは参照実装が何年も前にデフォルトで提供をやめた仕組みを使っており、それらのノードにあなたのアドレスについて何かを伝えています。コンパクトブロックフィルタに基づくウォレット（lndのNeutrinoの背後にある設計）は、はるかに少ない情報しか要求しません。ベンダー自身のサーバーに向けられたウォレットが第3の選択肢であり、最も一般的です。高速で、見知らぬ人からはプライバシーが保たれ、ベンダーには完全に見えます。
MSG_FILTERED_WITNESS_BLOCK vsマークルブロック
マークルブロックは答えであり、MSG_FILTERED_WITNESS_BLOCKはそれを生成するようにつながれたことのない要求です。merkleblockメッセージは、ブロックを送信せずに一連のトランザクションがブロックに属することを証明する、実際に実装された構造です。予約されたウィットネス変種は、その証明の後に来るもの、つまり一致するトランザクションが署名付きで届くかどうかだけを変えたはずです。包含証明はtxidで機能するため、欠けている機能は誰にも何のコストもかけませんでした。