Neutrino

Anna abre su cartera y espera ver un pago recibido. Para mostrarle el estado correcto, la aplicación debe obtener y procesar datos de la red Bitcoin. Neutrino puede encargarse de esa parte sin guardar permanentemente toda la cadena de bloques en el teléfono. Un bloque es un conjunto de transacciones registrado en el historial compartido de la red Bitcoin. En el programa, el servicio se llama ChainService: gestiona conexiones, una base de datos local y la sincronización de cabeceras. Una cabecera resume los datos básicos de un bloque. Una clave privada es un número secreto que permite crear una firma digital para autorizar un gasto. Usar Neutrino no determina quién guarda las claves privadas de Anna ni quién autoriza los envíos. La gestión de claves, las pantallas y las copias de seguridad corresponden a la cartera que utiliza la biblioteca. [1]

Un filtro compacto se parece a un pequeño índice de búsqueda de un bloque. La cartera lo descarga y comprueba en su propio dispositivo si coincide con lo que busca. En realidad compara scripts, las condiciones que permiten gastar determinadas salidas de Bitcoin. Una salida es la parte de una transacción que indica un importe y las condiciones para gastarlo después. La cartera no necesita enviar a la otra parte su lista completa de direcciones. Si hay una coincidencia, descarga el bloque correspondiente y busca la transacción real. Incluso un filtro correcto puede producir un falso positivo: se descarga un bloque innecesariamente porque no contiene el elemento buscado. Por tanto, una coincidencia no demuestra por sí sola que haya llegado un pago, cuál sea su importe ni que la cartera pueda gastarlo. [1] [2] [3]

Anna cambia de teléfono y restaura su cartera. Buscar solo desde los bloques de hoy no basta si recibió pagos antes. La aplicación debe proporcionar los scripts correctos y un punto de inicio suficientemente antiguo. Según la documentación, Rescan sin un bloque inicial especificado comienza en el último bloque conocido, no automáticamente al principio de toda la historia. Un filtro que funciona bien no encuentra una dirección que la cartera no busca ni pagos antiguos en bloques omitidos. Hay que distinguir una restauración terminada de un escaneo todavía en curso. Una lista vacía durante el proceso no demuestra que los fondos hayan desaparecido. [1]

Neutrino sincroniza cabeceras de bloques y de filtros. Las primeras permiten comprobar su enlace y el Proof of Work, la prueba del trabajo computacional realizado, y seguir la cadena con mayor trabajo acumulado. Eso es mucho más que aceptar a ciegas el saldo de un servidor, pero menos que verificar independientemente cada transacción y cada regla como hace un Full Node. Además, son dos cadenas de cabeceras distintas. Las cabeceras de Bitcoin no incorporan un compromiso directo con la corrección de estos filtros. Comprobar únicamente los hashes, huellas criptográficas, no descarta unos filtros fraudulentos pero internamente coherentes. El ahorro de trabajo tiene un límite de confianza concreto. [2] [4]

Un peer es otro ordenador de la red del que el cliente obtiene datos. BIP 157 se basa en comparar respuestas y disponer de al menos un peer honesto para detectar filtros incorrectos. Si un mismo atacante controla todas las conexiones, el número de ordenadores conectados no basta. Pueden dar la misma respuesta falsa u ocultar un estado más reciente. Este aislamiento de fuentes honestas está relacionado con un Eclipse Attack. La cartera necesita fuentes disponibles y suficientemente independientes, no solo conexiones. Un icono verde de conexión no prueba que ya tenga un historial de pagos completo y actualizado. [2]

Jan acaba de enviar dinero a Anna. Su transacción puede esperar primero en un Mempool, el conjunto local de transacciones sin confirmar de un nodo, hasta que un minero la incluya en un bloque. Las notificaciones documentadas recvtx y redeemingtx de Neutrino llegan al confirmarse en un bloque, no al entrar en un Mempool. Una aplicación que quiera mostrar pagos entrantes sin confirmar necesita otro mecanismo adecuado. Un filtro de bloque no puede revelar algo antes de que ese bloque exista. Envío, aceptación por un peer y confirmación son sucesos distintos; la ausencia de una notificación aún no demuestra que Jan no haya enviado nada. [1]

Una coincidencia del filtro solo sirve si el cliente consigue también el bloque necesario. Si la red no puede entregarlo en ese momento, la conclusión correcta es «todavía faltan datos», no «el saldo es cero». El estado también puede cambiar durante una reorganización: la red adopta otra rama con más trabajo acumulado y desconecta bloques antes incorporados. Rescan informa tanto de bloques conectados como desconectados para que la aplicación recalcule sus registros. La privacidad tampoco es absoluta: el peer no recibe la lista de direcciones buscadas, pero ve las solicitudes de bloques concretos y los datos de red de la conexión. La forma de obtener los datos sigue importando. [1] [2]

Lightning Network es una red de pagos construida sobre Bitcoin. En un canal de pago, dos participantes actualizan cómo se reparten los fondos compartidos, en lugar de registrar cada pago en un bloque de Bitcoin. Neutrino aporta datos de la cadena; no conserva por sí solo, por cuenta del usuario, la información necesaria para recuperar el estado actual de esos canales. Recuperar el historial de la cartera y recuperar canales son tareas distintas. El README describe el almacenamiento de los filtros solicitados y la descarga de bloques sin guardarlos permanentemente; las necesidades reales dependen de la versión y configuración de la aplicación. Antes de confiar en esa cartera, conviene entender su procedimiento de copia y recuperación y qué hace cuando fallan las fuentes de datos. Una base de datos más pequeña en el teléfono no elimina esas responsabilidades. [1] [4]