-
Las semillas de recuperación son utilizadas por las carteras determinísticas (HD).
-
El desarrollador ghost43, autor de la propuesta, trabaja actualmente para la wallet Electrum.
Debido a limitantes propias del protocolo de la red Lightning, aún no es posible encontrar con un respaldo real de los canales de pago. Sin embargo, el programador de la wallet Electrum conocido como ghost43, publicó lo que sería una lista de desafíos y posibles caminos a tomar para que los usuarios cuenten con una semilla de recuperación utilizable.
La propuesta fue publicada en la lista de correo Lightning-dev, dedicada a las discusiones con respecto al ecosistema de la red de micropagos de Bitcoin. En este caso, ghost43 analiza como Electrum, con sus implementaciones actuales en la red Lightning, podría buscar una solución. Recordando que Electrum es compatible con esta red desde mediados del 2020, según lo reportó CriptoNoticias.
La principal problemática planteada se encuentra en el protocolo mismo de la red, que utiliza lo que se conoce como compromisos de pago. La semilla de una wallet determinística (HD por sus siglas en inglés), solo puede recuperar las claves privadas de las diferentes direcciones públicas que posean fondos. Las wallets HD son aquellas que utilizan un sistema de recuperación basado una frase mnemotécnica, conocida también como semilla.
En el caso de la red Lightning, los BTC, básicamente, se encuentran guardados en lo que se conoce como una transacción de compromiso, la cual no es propagada en la red, y por lo tanto no puede ser recuperada utilizando una semilla del tipo BIP32. En caso de perder acceso a los canales, se recurre a lo que se conoce como cierre forzado, lo cual transferirá los fondos desde la red Lightning a la cadena principal de Bitcoin, pero con un tiempo de espera aproximado de 2 semanas.
En este caso, se pretende crear una semilla de recuperación, que permita acceder nuevamente a los canales de pago, sin la necesidad de utilizar los cierres forzados.
Soluciones ante la problemática
El programador divide en tres las posibles soluciones al problema, comenzando por crear lo que sería una clave estática o clave de recuperación, que se derivaría de la semilla de recuperación, al momento de generar la transacción de compromiso de apertura del canal. Es decir, la transacción de creación estaría ligada a la clave pública que creó el canal gracias a una clave que se insertaría en la transacción.
Sin embargo, como expresa el propio ghost43, esto podría ser un problema de privacidad dado que cada transacción de creación de un nuevo canal sería identificable dentro de la cadena de bloques.
La segunda propuesta establece crear un nuevo tipo de derivación de semillas de recuperación. Estas permiten recuperar el valor de los canales abiertos por el usuario (payment_basepoint) por medio de un nuevo sistema y clave que esté desarrollado única y particularmente para recuperar los BTC en los canales de pago.
Por último, el desarrollador también sugiere una solución ya utilizada por la cartera Eclair, la cual derivaría las claves a partir de una semilla de recuperación dentro de las transacciones multifirma 2 de 2 para la generación del canal de pago (todos los canales de pago se crean a través de transacciones multifirma 2 de 2). El desafío acá estaría en que, con la llegada de Taproot, las transacciones multifirma no se diferenciarían de cualquier otra, llevando a un nuevo desafío en este método de derivación.
Por ahora, ghost43 considera esto como una propuesta, habiendo aún desafíos que afrontar para llevar a cabo cualquiera de las implementaciones, proponiendo incluso lo que sería un cambio de protocolo al momento de abrir el canal de pago dentro de la red Lightning.
