Payment Channel

Imagina dos partes que actualizan sus derechos sobre un importe bloqueado conjuntamente. Cada pago no necesita su propia transacción de Bitcoin en un bloque: ambas partes intercambian firmas para un nuevo estado. No es una simple hoja de cálculo en la que deban confiar. Disponen de transacciones con las que pueden hacer cumplir la liquidación según las condiciones acordadas. [1] [2]

La transacción de financiación es la que que aporta bitcoins al canal. Su salida es un importe sujeto a reglas sobre quién puede gastarlo; una confirmación significa que la transacción se ha incluido en un bloque. En un canal Lightning habitual, esa salida exige las firmas de ambas partes: 2-of-2. Antes de publicar esa financiación, los participantes deben tener una vía válida de cierre unilateral. Normalmente se esperan confirmaciones. En ciertas condiciones, zero-conf permite usar el canal sin esperar confirmaciones. El receptor depende entonces más de quien aporta los fondos: la transacción aún no está confirmada y podría ser sustituida por otra que gaste los mismos fondos. [2] [3]

Una commitment transaction es una transacción firmada de antemano para liquidar el reparto acordado. Aquí, un nodo es el programa que gestiona el canal y sus actualizaciones. Cada parte tiene su propia versión de la transacción commitment. Al actualizar, los nodos coordinan firmas y secretos de revocación mediante commitment_signed y revoke_and_ack. Un acuerdo posterior no invalida una transacción antigua firmada según el consenso de Bitcoin. Por eso, la protección frente a la publicación de un estado revocado debe estar en las condiciones de las salidas. [2] [3]

En un canal de revocación habitual, quien publica su commitment debe esperar to_self_delay para gastar sus propios fondos. La espera se cuenta en bloques desde la confirmación de la transacción commitment. Si publicó un estado revocado, la otra parte puede utilizar la clave de revocación para gastar las salidas afectadas como medida correctiva. Debe actuar a tiempo y conseguir una confirmación. Un Watchtower es un servicio que vigila la cadena y puede usar datos preparados de antemano para responder a la publicación de un estado revocado. Aun así, el servicio no garantiza el éxito ni sustituye una copia de seguridad. [3] [4]

Sat es la abreviatura de satoshi, la unidad más pequeña de bitcoin en la cadena. La capacidad es el importe total del canal, no el saldo de cada participante. Supongamos un canal de 100000 sat: Alice tiene 70000 sat y Bob 30000 sat. Si Alice paga a Bob 10000 sat, el reparto pasa a 60000 sat y 40000 sat. Para simplificar, omitimos comisiones y reservas. La capacidad no cambia, pero Alice puede enviar menos y recibir más. Las reservas y los pagos pendientes también afectan a los límites reales. [6]

Lightning busca rutas por varios canales conectados. Un HTLC es un pago condicionado: para reclamar los fondos hay que revelar un secreto, la preimage, cuyo hash o huella digital coincida con el valor conocido de antemano. Las condiciones temporales también permiten liquidar si el pago no se completa. Los intermediarios necesitan liquidez, es decir, fondos disponibles para enviar en la dirección necesaria, y pueden cobrar comisiones. No hace falta un canal directo con cada comercio, pero una conexión no garantiza una ruta utilizable para cualquier importe. [2] [4]

En un cierre de mutuo acuerdo, o cooperative close, los participantes acuerdan la transacción de cierre, el reparto y la comisión. Ambos la firman y la publican en la cadena. Suele ser más sencillo que una liquidación unilateral, pero no es automáticamente gratuito ni inmediato. También necesita confirmación y una comisión adecuada a las condiciones de la red. [2] [4]

Un cierre unilateral, o force close, permite publicar el commitment actual propio sin obtener un nuevo consentimiento de la contraparte. Los fondos pueden no estar disponibles de inmediato: siguen aplicándose las esperas y la posible resolución de HTLC. Puede hacer falta pagar más transacciones y comisiones. Existe una salida de emergencia, pero su duración y coste dependen del estado del canal y de la cadena. [3] [4]

Una Seed Phrase es un conjunto de palabras de respaldo con las que una cartera recupera sus claves. Por sí sola no recupera el último estado de un canal abierto; sigue el procedimiento de tu cartera. Por ejemplo, LND, un programa para operar un nodo Lightning, combina esas palabras con un Static Channel Backup (SCB). Esta copia estática guarda los datos necesarios para contactar con las contrapartes y pedirles que cierren los canales; no los restaura para seguir pagando. La recuperación también depende de que las contrapartes respondan. En cambio, channel.db contiene la base de datos de canales, y una copia antigua puede guardar un estado peligrosamente desactualizado. Nunca introduzcas tus palabras de respaldo reales en una web ajena para «reparar» un canal. [5]

Averigua quién guarda las claves, quién vigila los canales y cómo recuperarás el acceso si pierdes el dispositivo. Custodial significa que el proveedor del servicio guarda las claves. Un saldo Lightning en un servicio custodial no tiene por qué ser tu propio canal. Con la autocustodia asumes las copias de seguridad, la disponibilidad y la respuesta a problemas. Los canales ahorran registros en la cadena, pero no eliminan todas las obligaciones operativas ni los costes de liquidación. [4] [5]