Lightning Watchtower es un servicio que vigila la cadena de Bitcoin por un usuario de un canal de pago. Si la otra parte publica un estado revocado, puede emitir una transacción de recuperación preparada previamente. Ayuda a proteger los fondos mientras el nodo está desconectado, pero necesita datos correctos, conectividad y una confirmación a tiempo. Un nodo es el programa que gestiona los canales y procesa los pagos de Lightning; mientras está desconectado, no puede comunicarse con los demás participantes.
Anna y Pavel tienen un canal de pago: sus fondos están bloqueados conjuntamente en Bitcoin y los pagos por Lightning cambian cómo se reparten. Pavel paga a Anna, ambos acuerdan los nuevos saldos y revocan el estado anterior. Después, Anna pierde la conexión. Si Pavel publicara el estado antiguo, podría intentar recuperar dinero que ya gastó. Anna puede recurrir a un Lightning Watchtower para cubrir esta situación. Su nodo le envía previamente datos cifrados para proteger los estados revocados. Cuando el servicio reconoce la transacción correspondiente en la cadena, puede emitir una transacción de recuperación sin que Anna esté conectada. No hace pagos por ella ni arregla la conexión de su nodo. [1] [8]
Cada reparto acordado tiene una commitment transaction: una transacción firmada que permite cerrar el canal en la cadena de Bitcoin. Al actualizarlo, los participantes intercambian información que permite penalizar la publicación del estado anterior, ya revocado. Aquí describimos ese modelo de canal con penalizaciones. Si Pavel utiliza el estado válido actual, puede cerrar el canal unilateralmente aunque Anna esté desconectada. El Watchtower no debe impedirlo. Actúa contra un estado revocado concreto, tanto si Pavel lo publicó a propósito como si lo hizo por error desde una copia de seguridad antigua. Lo decisivo es la revocación, no la edad de la transacción. [1] [8]
Una Seed Phrase es una copia de seguridad expresada en palabras que permite recuperar las claves privadas necesarias para firmar pagos. LND es uno de los programas utilizados para operar un nodo Lightning. Anna no entrega su Seed Phrase ni las claves privadas de toda su cartera. Proporciona datos y firmas limitados a una respuesta concreta; LND llama JusticeKit a ese paquete. La transacción de recuperación, denominada justice transaction, devuelve los fondos protegidos según condiciones preparadas previamente. Esto no autoriza al Watchtower a gastar otras monedas de Anna. En el modelo sin recompensa para el servicio, se descuenta de la cantidad protegida la comisión de la transacción de Bitcoin. El código también contempla tipos con recompensa para la torre, pero eso no demuestra que un operador concreto ofrezca un servicio de pago. [3] [4] [5]
Para ayudar, el Watchtower tiene que recibir realmente los datos. No basta con introducir su dirección en la configuración o ver una tarea en la cola de envío. El cliente, la parte del nodo de Anna que se comunica con la torre, necesita acuses de recibo de las actualizaciones. Puede fallar la conexión, agotarse la capacidad de un acuerdo de almacenamiento llamado session o rechazarse una copia. Por eso Anna también debe revisar los envíos pendientes y los errores. Ni siquiera los datos aceptados garantizan el éxito: la torre debe seguir la cadena correcta y conseguir que su respuesta se confirme en un bloque a tiempo. [6] [8]
Si Anna pierde su dispositivo, no lo restaurará desde el Watchtower. El servicio vigila el uso de estados revocados; no recupera su cartera ni soluciona el robo de claves. LND utiliza Static Channel Backup (SCB) para recuperar canales. Junto con la semilla de la cartera, permite recuperar fondos cerrando canales, no continuar exactamente donde se interrumpió el nodo. SCB no es una copia de cada actualización ni el paquete cifrado enviado a la torre. Arrancar una base de datos channel.db antigua sin el procedimiento de recuperación adecuado es especialmente peligroso: el nodo podría publicar su propio estado revocado. Sigue las instrucciones de copia y recuperación de tu cartera y versión concretas. [7]
Una salida de transacción indica una cantidad y las condiciones para gastarla. La protección funciona porque quien publica su estado del canal no puede gastar inmediatamente su salida retardada. BOLT 3 llama to_local a esa salida y to_self_delay al plazo de espera. CSV es la regla que mide ese plazo en bloques desde la confirmación de la salida. La otra parte puede utilizar la vía de penalización sin esa espera si dispone de la clave de revocación correcta. Así, el Watchtower tiene margen para actuar primero. Al terminar el plazo, la vía de penalización no desaparece, pero la otra parte también puede gastar los fondos. El resultado depende de cuál de los gastos incompatibles se confirme válidamente. Emitir la transacción de recuperación no basta, y un número de bloques no equivale a un número exacto de horas. [1] [9]
Antes de elegir un servicio, comprueba qué protege realmente. Los HTLC son pagos condicionales que pueden seguir pendientes en el canal; vigilar saldos no demuestra que estén cubiertos. Dust designa aquí una salida demasiado pequeña para incluirla en esa transacción. El backupTask verificado de LND v0.21.3-beta prepara las salidas to_local y to_remote del commitment revocado que existen y no se clasifican como Dust. No incluye protección general de todas las salidas HTLC; la documentación correspondiente la presenta como ampliación futura. Bitcoin Script es el lenguaje que expresa las condiciones para gastar una salida. Que permita gastar una salida mediante una penalización no significa que una torre concreta haya recibido los datos necesarios ni que pueda ejecutar esa protección. [3] [5]
El paquete cifrado evita que la torre necesite leer continuamente todos los saldos de Anna. Busca coincidencias mediante una marca corta y descifra los datos con información de la transacción reconocida. Lo siguiente es una referencia técnica para una versión concreta de LND; txid es el identificador de una transacción y blob un paquete de datos. En LND v0.21.3-beta, BreachHint son los primeros 16 bytes del SHA-256 del txid binario. BreachKey se obtiene aplicando SHA-256 al mismo txid binario concatenado consigo mismo. No son los primeros 16 caracteres del txid mostrado ni su primera mitad sin más. El cliente cifra un JusticeKit; conocer la transacción correspondiente permite derivar la clave y descifrar los datos. [2] [3]
Operar una torre para otros y proteger tus propios canales son tareas distintas. Esta configuración es para operadores de LND; RPC es la interfaz por la que el programa recibe instrucciones. LND separa watchtower.active para el servidor de wtclient.active para el cliente. Activar solo el servidor no configura copias de tus propios canales en otra torre. lncli tower info muestra pubkey, listeners y uris del servidor; lncli wtclient add registra una torre para el cliente. La clave pública de la torre difiere de la del nodo Lightning. Comprueba red, accesibilidad de la dirección y compatibilidad RPC de la compilación usada. [5]
La respuesta debe pagar espacio en un bloque de Bitcoin. Un satoshi es la unidad más pequeña de bitcoin. El byte virtual mide el tamaño de la transacción teniendo en cuenta el distinto peso de sus componentes. La tarifa se expresa en satoshis por byte virtual de la transacción, no como porcentaje del dinero protegido. En LND v0.21.3-beta, el campo sweep_sat_per_vbyte de policy y session indica la tasa en sat/vB. La comisión reduce el importe devuelto. backupTask puede rechazar un estado por valor insuficiente o parámetros de session inadecuados; no toda tarea preparada es una copia elegible. Un cambio posterior de configuración no demuestra cambios en transacciones ya firmadas, y una tasa insuficiente puede retrasar la intervención. [3] [6]
Una segunda torre puede ayudar si falla la primera solo si también recibió los datos necesarios. La independencia incluye la conexión y el operador, no solo el nombre del servicio. Varias torres independientes y la vigilancia propia pueden reducir el impacto de un fallo. Comprueba qué actualizaciones concretas recibió cada torre; registrar varias direcciones no demuestra que todos los estados estén replicados. Separar máquinas, redes y ubicaciones reduce fallos compartidos. Los blobs cifrados y las conexiones autenticadas limitan la visibilidad de los saldos, pero no eliminan metadatos, la exposición de la frecuencia de actualización ni el riesgo de correlación. [5] [8]
Al revisar la protección, distingue una actualización enviada de una realmente recibida. Estos comandos y campos son una referencia más detallada para administrar LND; el acuse de una copia no es la confirmación de una transacción en un bloque. Usa lncli wtclient towers, lncli wtclient tower, lncli wtclient stats y lncli wtclient policy. En LND v0.21.3-beta, distingue num_backups de num_pending_backups; el segundo cuenta copias pendientes de confirmación por la torre. num_failed_backups en la respuesta stats cuenta copias fallidas sin confirmar. Las estadísticas abarcan desde el inicio del cliente. active_session_candidate identifica un candidato para sessions, no demuestra protección completa. [6]
Configurar bien el servicio es el comienzo. Una prueba debe cubrir desde la detección del estado revocado hasta la recuperación de los fondos protegidos; no la hagas con tu dinero real. Comprueba las versiones concretas del cliente y la torre, los tipos de canal y session compatibles, la actualización de los datos, las comisiones y la sincronización con la cadena. Prueba la respuesta en un entorno de ensayo aislado; un cierre unilateral ordinario (force close) no demuestra una intervención contra un estado revocado. El resultado se acredita con la infracción correspondiente, la justice transaction reconstruida y sus salidas confirmadas. Una demostración exitosa no garantiza disponibilidad futura ni elimina todos los riesgos de Lightning. [1] [3] [6]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Payment Channel, Autocustodia. También enlazan con esta entrada Payment Channel.