Neutrino — реалізація легкого клієнта мовою Go від Lightning Labs, розрахована також на мобільне використання з Lightning Network. Вона використовує BIP 157 і BIP 158; це не назва будь-якого легкого клієнта й не самостійна заміна Full Node.
Застосунок запускає ChainService, який керує з’єднаннями з вузлами, базою даних і синхронізацією заголовків. Гаманець шукає через нього надходження й витрати. Саме використання Neutrino не визначає, хто тримає приватні ключі чи схвалює платежі; ці функції та резервні копії належать застосунку вищого рівня. [Lightning Labs — Neutrino README]
Клієнт синхронізує заголовки блоків і фільтрів, за потреби отримуючи фільтри та відповідні блоки. Він перевіряє власні скрипти локально. Збіг може бути хибнопозитивним, тому потрібно оглянути справжній блок і знайти транзакцію. Сам фільтр не дає ні суми, ні доказу контролю виходу конкретним гаманцем. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Легкий клієнт перевіряє заголовки та їхні зв’язки, але не перевіряє самостійно кожну транзакцію й умову консенсусу як Full Node. До того ж ланцюг заголовків фільтрів не зафіксований у заголовках Bitcoin. Самої перевірки їхніх хешів недостатньо, щоб виключити внутрішньо узгоджені шахрайські фільтри. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 покладається на порівняння відповідей і принаймні один чесний вузол для виявлення неправильних фільтрів. Кілька з’єднань із машинами одного нападника не виконують цю умову. Ізоляція може приховати від клієнта платежі чи новий стан ланцюга; потрібні доступні різноманітні джерела, а не просто ненульова кількість з’єднань. [BIP 157 — Client Side Block Filtering]
README описує Rescan з необов’язковим початковим і кінцевим блоком; без початку сканування йде від останнього відомого блока. Це не автоматичний пошук усієї історії відновленого гаманця. Застосунок має надати достатньо ранній початок і повний набір спостережуваних скриптів; правильний фільтр не знайде адресу, яку клієнт не шукає. [Lightning Labs — Neutrino README]
Документовані події recvtx і redeemingtx надходять при підтвердженні, а не вже при вході транзакції до Mempool. Тому гаманцю, що показує непідтверджені платежі, потрібен відповідний додатковий механізм. Розсилання, прийняття вузлом і підтвердження в блоці — різні події; відсутність сповіщення сама не доводить, що нічого не надіслано. [Lightning Labs — Neutrino README]
Rescan повідомляє про приєднані й від’єднані блоки, щоб застосунок перерахував стан після реорганізації. Фільтр зі збігом усе ще потребує справжнього блока; недоступність не можна показувати як нульовий баланс. Вузол бачить запити блоків і мережеві дані, навіть не отримуючи списку адрес, які шукає клієнт. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
README описує збереження запитаних фільтрів і завантаження блоків без постійного зберігання; фактичну роботу перевіряй для конкретної версії й конфігурації. Neutrino постачає дані ланцюга, а не резервну копію поточного стану каналів Lightning. Перед упровадженням окремо перевір відновлення історії, втрату вузлів, реорганізацію й процедуру відновлення каналів застосунку. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Для повної картини прочитайте також Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. На цю статтю також посилаються Compact Block Filters, Compact Block Filters.