Neutrino es la implementación de cliente ligero en Go de Lightning Labs, diseñada también para uso móvil con Lightning Network. Usa BIP 157 y BIP 158; no es el nombre de todos los clientes ligeros ni un sustituto autónomo de un Full Node.
La aplicación inicia ChainService, que gestiona conexiones con pares, base de datos y sincronización de cabeceras. La cartera lo utiliza para buscar ingresos y gastos. Usar Neutrino no determina quién posee las claves privadas o aprueba los pagos; esas funciones y las copias de seguridad pertenecen a la aplicación que lo integra. [Lightning Labs — Neutrino README]
El cliente sincroniza cabeceras de bloques y filtros y obtiene filtros y bloques coincidentes cuando los necesita. Prueba sus scripts localmente. Una coincidencia puede ser un falso positivo, por lo que debe examinar el bloque real y encontrar la transacción. El filtro no aporta por sí solo el importe ni prueba que una cartera controle una salida. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Un cliente ligero comprueba cabeceras y su encadenamiento, pero no verifica independientemente cada transacción y condición de consenso como un Full Node. Además, la cadena de cabeceras de filtros no está comprometida en las cabeceras Bitcoin. Verificar sus hashes no descarta por sí solo filtros fraudulentos internamente coherentes. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 se basa en comparar respuestas y disponer de al menos un par honesto para detectar filtros incorrectos. Varias conexiones a máquinas del mismo atacante no cumplen esa condición. Aislar al cliente puede ocultarle pagos o un nuevo estado de cadena; necesita fuentes disponibles y diversas, no solo alguna conexión. [BIP 157 — Client Side Block Filtering]
El README describe Rescan con bloques inicial y final opcionales; sin inicio, escanea desde el último bloque conocido. Eso no busca automáticamente todo el historial de una cartera restaurada. La aplicación debe aportar un inicio suficientemente temprano y todos los scripts vigilados; un filtro correcto no encuentra una dirección que el cliente no busca. [Lightning Labs — Neutrino README]
Los eventos documentados recvtx y redeemingtx llegan al confirmarse, no al entrar la transacción en Mempool. Una cartera que muestre pagos sin confirmar necesita otro mecanismo adecuado. Difusión, aceptación por un par y confirmación en bloque son eventos distintos; la ausencia de aviso no demuestra por sí sola que no se enviara nada. [Lightning Labs — Neutrino README]
Rescan avisa de bloques conectados y desconectados para que la aplicación recalcule su estado tras una reorganización. Un filtro coincidente sigue necesitando el bloque real; su indisponibilidad no debe mostrarse como saldo cero. El par observa peticiones de bloques y datos de red aunque no reciba la lista de direcciones buscadas. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
El README describe almacenar filtros solicitados y cargar bloques sin guardarlos permanentemente; comprueba el funcionamiento según versión y configuración. Neutrino aporta datos de cadena, no una copia del estado actual de los canales Lightning. Antes de desplegar prueba por separado recuperación del historial, pérdida de pares, reorganización y recuperación de canales de la aplicación. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Para obtener la imagen más completa, lee esta entrada junto con Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Ataque de eclipse. También enlazan con esta entrada Compact Block Filters, Compact Block Filters.