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.