Compact Block Filters — невеликі зведення вмісту блоків Bitcoin. Гаманець завантажує їх і на власному пристрої з’ясовує, які блоки можуть містити його платежі. Лише після цього він запитує потрібні блоки повністю. Це заощаджує трафік і менше розкриває мету пошуку. Однак збіг у фільтрі ще не доводить наявності платежу й не замінює повної перевірки правил Bitcoin.
Анна чекає на платіж у мобільному гаманці. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Блоки — це набори транзакцій, але телефон не мусить завантажувати кожен набір повністю. Спочатку він може переглядати невеликі фільтри, наче читач, який шукає потрібну сторінку за покажчиком у книжці. Для того самого блоку й типу фільтра всі отримують однакове зведення; відбір важливого для Анни відбувається вже в телефоні. Технічні документи BIP 157 і BIP 158 розділяють завдання: перший описує отримання та перевірку фільтрів, другий — їхній вміст і побудову. Гаманець спочатку перевіряє заголовки блоків, тобто основні дані, які пов’язують блоки в ланцюг, а потім отримує контрольні дані фільтрів і самі фільтри. Якщо є збіг, він завантажує цілий блок і шукає справжню транзакцію. Подібна назва Compact Blocks із BIP 152 стосується іншої задачі: швидкого передавання нових блоків між вузлами. Вузол — програма, що перевіряє транзакції та блоки й обмінюється даними з іншими учасниками мережі. [1] [2] [5] [6]
Транзакція Bitcoin створює виходи: суми з умовами їх подальшого витрачання. Код цих умов називається scriptPubKey. Вхід нової транзакції посилається на попередній вихід, який вона витрачає. Тому фільтр basic із позначенням 0x00 містить як скрипти нових виходів, так і скрипти попередніх виходів, витрачених у блоці. Анна може шукати і надходження, і витрачання коштів. Нові скрипти з початковим 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 — перші 16 байтів хешу блоку в порядку little-endian, тобто від молодших байтів. Це не таємний ключ гаманця. Тут SipHash перетворює елементи на числа для фільтра, а не шифрує їх. Запис фільтра починається з N у форматі CompactSize для невід’ємних цілих чисел. [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]
Для повної картини прочитайте також Neutrino, Full Node, Pruned Node, Приватність у Bitcoin, Compact Blocks, Mempool. На цю статтю також посилаються Compact Block Filters, Neutrino.