Backup en cliente LND

Este artículo tiene una fecha de caducidad muy próxima, LND tiene como hito para la versión 0.6 los backups en cliente. Podéis ver más información aquí.

Sin embargo considero necesario aclarar el estado actual ya que veo muchas dudas e informaciones erróneas.

Lo primero decir que el artículo se refiere al cliente LND, no conozco el estado de los backup en otros clientes como C-Lightning o Eclair. Si lo conoces te agradezco que lo pongas en comentarios. Hay otras opciones como la cartera móvil Bitcoin Lightning Wallet que si tienen una solución de backup (Off-chain data loss protection).

Este es el estado actual del cliente LND:

El cliente LND utiliza Bolt que es una base de datos en Go. Vamos a fijarnos en 2 de ellas.

wallet.db

Esta base de datos contiene lo relacionado con las direcciones que controlamos y que se generan a partir de las claves privadas que, a su vez, se derivan de la semilla que apuntamos al arrancar por primera vez el cliente.

Si nuestro nodo tuviera algún problema o el fichero se corrompiera, sería suficiente con esa semilla para recuperar los fondos.

channel.db

Esta base de datos contiene toda la información sobre nuestros canales, pares, rutas, comisiones…

Si perdemos este fichero, perdemos todos los fondos que tengamos en canales.

¿Por qué ocurre esto? Obviamente perdemos el control sobre nuestros canales, y toda la información sobre ellos incluida la transacción de cierre de canal que se genera en cada cambio en el balance del canal. La otra parte verá el canal como inactivo y finalmente forzará el cierre (a nadie nos gusta tener canales inactivos), la transacción de cierre crea 2 output, uno para cada integrante del canal y tras el timelock (que se activa por ser un cierre forzado) el cliente LND construye la transacción que reclama ese output. Para realizar esta tx utiliza datos que se encuentran en el fichero channel.db, fichero que ya no tenemos.

Tx de cierre, vemos como un output ha sido gastado pero el otro no, este último es de un nodo con el channel.db corrupto

En la parte de backup de nuestra guía lo que hacemos es copiar todo el directorio de datos, pero esta opción también tiene riesgos.

  • Fichero corrupto
    • Si nuestro fichero channel.db esta corrupto, haremos backup de él y con ello anularemos el backup, se puede solucionar fácilmente haciendo un versionado de backups y comprobando la integridad de la copia con herramientas como bolt.
Comprobar integridad de la BBDD
  • Cambios en los canales
    • Si el balance de nuestros canales ha cambiado posterior a un backup al recuperar dicho backup propagaremos un estado antiguo, el otro lado del canal detectará este comportamiento y forzará el cierre del canal (este comportamiento puede variar en función de la versión de LND que tengamos, ver <data-loss-protection>)

¿Es mejor recuperar un backup? Con cuidado, normalmente es mejor consultar en grupos a gente con conocimientos sobre este tipo de procedimientos, tenéis un grupo de Telegram es castellano.

Como vemos el estado actual es precario en LND, también es cierto que la corrupción o la pérdida de estos ficheros no es algo común y se produce más por mal uso que de manera espontánea.

Como he comentado al principio de este artículo esto cambiará en el cliente LND en breve, y podremos olvidar este tema. Hasta entonces recordar, #reckless

Añadir un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *