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.