Neutrino é a implementação de cliente leve em Go da Lightning Labs, pensada também para uso móvel com Lightning Network. Usa BIP 157 e BIP 158; não designa todos os clientes leves nem substitui autonomamente um Full Node.
A aplicação inicia ChainService, que gere ligações a pares, base de dados e sincronização de cabeçalhos. A carteira usa-o para encontrar entradas e despesas. Utilizar Neutrino não determina quem detém as chaves privadas ou aprova pagamentos; essas funções e as cópias de segurança pertencem à aplicação envolvente. [Lightning Labs — Neutrino README]
O cliente sincroniza cabeçalhos de blocos e filtros e obtém filtros e blocos correspondentes conforme necessário. Testa os seus scripts localmente. Uma correspondência pode ser um falso positivo, exigindo examinar o bloco real e encontrar a transação. O filtro sozinho não fornece o montante nem prova que determinada carteira controla uma saída. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Um cliente leve verifica cabeçalhos e a sua ligação, mas não valida independentemente todas as transações e condições de consenso como um Full Node. Além disso, a cadeia de cabeçalhos de filtros não está comprometida nos cabeçalhos Bitcoin. Verificar apenas os hashes não exclui filtros fraudulentos internamente consistentes. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 depende da comparação de respostas e de pelo menos um par honesto para detetar filtros incorretos. Várias ligações a máquinas do mesmo atacante não cumprem essa condição. Isolar o cliente pode ocultar pagamentos ou um novo estado da cadeia; são necessárias fontes disponíveis e diversas, não apenas alguma ligação. [BIP 157 — Client Side Block Filtering]
O README descreve Rescan com blocos inicial e final opcionais; sem início, pesquisa a partir do último bloco conhecido. Isso não percorre automaticamente todo o histórico de uma carteira restaurada. A aplicação deve fornecer um ponto suficientemente antigo e todos os scripts vigiados; um filtro correto não encontra uma morada que o cliente não procura. [Lightning Labs — Neutrino README]
Os eventos documentados recvtx e redeemingtx chegam na confirmação, não quando a transação entra no Mempool. Uma carteira que mostra pagamentos por confirmar precisa de outro mecanismo adequado. Difusão, aceitação pelo par e confirmação em bloco são eventos diferentes; a falta de aviso não prova sozinha que nada foi enviado. [Lightning Labs — Neutrino README]
Rescan comunica blocos ligados e desligados para a aplicação recalcular o estado após uma reorganização. Um filtro correspondente continua a precisar do bloco real; a indisponibilidade não deve aparecer como saldo zero. O par observa pedidos de blocos e dados de rede mesmo sem receber a lista de moradas procuradas. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
O README descreve guardar filtros pedidos e carregar blocos sem os conservar permanentemente; verifica o funcionamento segundo a versão e configuração. Neutrino fornece dados da cadeia, não uma cópia do estado atual dos canais Lightning. Antes da utilização testa separadamente recuperação do histórico, perda de pares, reorganização e recuperação de canais da aplicação. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Para ter uma visão mais completa, leia este verbete junto com Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. Também há referências a este verbete em Compact Block Filters, Compact Block Filters.