Compact Block Filters — вероятностные индексы блоков для лёгких клиентов. Кошелёк скачивает фильтр и проверяет свои скрипты локально, а не отправляет серверу личный адресный фильтр как в BIP 37. BIP 157 и BIP 158 имеют статус Deployed при проверке, но не заменяют полную проверку консенсуса.
BIP 157 определяет getcfilters/cfilter, getcfheaders/cfheaders и getcfcheckpt/cfcheckpt. BIP 158 задаёт фильтр basic типа 0x00. Клиент сначала синхронизирует заголовки блоков, затем заголовки фильтров и фильтры; при совпадении скачивает блок и находит реальные транзакции. Это не Compact Blocks из BIP 152 для быстрой ретрансляции блоков. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Фильтр содержит scriptPubKey новых выходов, кроме скриптов с начальным OP_RETURN, и скрипты предыдущих выходов, расходуемых входами, кроме входа coinbase. Пустые элементы исключаются; элементы образуют множество. Это не индекс всех txid, строк адресов или данных witness; для построения нужны также расходуемые предыдущие выходы. [BIP 158 — Compact Block Filters for Light Clients]
Значения SipHash-2-4 отображают в диапазон N × M, сортируют, а разницы кодируют Golomb-Rice. Basic использует P=19 и M=784931; ключ — первые 16 байтов хеша блока в little-endian. Сериализация начинается с N в CompactSize. Запрос неэлемента может ложно совпасть с вероятностью около 1/M; правильный фильтр не пропускает включённый элемент. [BIP 158 — Compact Block Filters for Light Clients]
Хеш фильтра — double-SHA256 его сериализации. Заголовок — double-SHA256 этого хеша, соединённого с предыдущим заголовком фильтра. Это даёт проверяемую связь, но обязательство отсутствует в консенсусном заголовке блока. Само хеширование не обнаружит согласованно ложную цепь от всех подключённых пиров. [BIP 157 — Client Side Block Filtering]
BIP 157 рекомендует несколько независимых пиров, если нет защищённого соединения с доверенным. При разногласии клиент находит первую разницу и проверяет фильтр по блоку и необходимым данным предыдущих выходов. Гарантия правильных фильтров предполагает хотя бы одного честного пира. После реорганизации фильтры должны следовать новой ветви, а соответствующее состояние кошелька нужно пересчитать. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Локальная проверка не раскрывает пиру искомые скрипты. Но последующие запросы полных блоков показывают интерес и могут коррелировать с IP или повторными запросами. BIP 157 рекомендует случайно выбирать источники блоков среди исходящих пиров; источник блока не обязан раздавать фильтры. Это не гарантия анонимности. [BIP 157 — Client Side Block Filtering]
Фильтр относится к подтверждённому блоку, а не текущему Mempool. Совпадение не доказывает платёж или право расходования; это определяют транзакции и необходимые проверки. Узел может сохранить фильтры после обрезки блоков, но тогда не всегда предоставит старый полный блок. Экономия лёгкого клиента не заменяет модель безопасности Full Node. [BIP 157 — Client Side Block Filtering]
В Bitcoin Core 29.0 параметр -blockfilterindex создаёт индекс; -peerblockfilters включает раздачу пирам и требует индекс basic. NODE_COMPACT_FILTERS сигнализирует службу. RPC getblockfilter возвращает filter и header для выбранного блока. Наличие RPC или индекса само не означает раздачу фильтров по P2P; статья не меняет конфигурацию узла. [Bitcoin Core 29.0 — getblockfilter RPC] [Bitcoin Core 29.0 — Filter service configuration]
Для полной картины прочитайте эту статью вместе с Neutrino, Full Node, Pruned node, Приватность в Bitcoin, Compact block relay. На эту статью также ссылаются Compact Block Filters, Neutrino.