Un Submarine Swap permite pagar a través de Lightning Network con bitcoin que tienes en la cadena. La cadena es el historial público de transacciones de Bitcoin; Lightning permite pagos rápidos sin registrar cada pago por separado en ese historial. El sentido contrario se llama Reverse Submarine Swap. No compras otra moneda: tras descontar las comisiones, trasladas valor entre estas dos formas de pagar. Las condiciones criptográficas y temporales vinculan ambos pagos. La aplicación debe verificarlas y completar el intercambio a tiempo o gestionar la recuperación de los fondos.
Anna guarda bitcoin en una cartera corriente y una tienda le presenta una factura Lightning, una solicitud de pago. Un swap normal permite bloquear bitcoin en la cadena bajo unas condiciones y que el servicio pague la factura a cambio. Para llevar saldo Lightning a una dirección en la cadena necesita el sentido inverso: un Reverse Submarine Swap, como Loop Out. No tiene que cerrar sus canales de pago. El intercambio no crea dinero y el pago Lightning sigue necesitando una ruta disponible. [1] [4]
Podemos comprobar la huella digital de un secreto, pero en la práctica no podemos reconstruir ese secreto a partir de su huella. Ese valor secreto se llama preimage. Su huella digital es un hash, calculado mediante SHA256. Los pagos condicionados HTLC combinan esa huella con un plazo. En el swap inverso, la aplicación de Anna genera el secreto. El servicio mantiene pendiente su pago Lightning y bloquea el bitcoin correspondiente en la cadena. Al recogerlo mediante una operación claim, Anna revela el secreto en la cadena o lo comparte con el servicio al cooperar. Así el servicio puede liquidar el pago vinculado. Pendiente todavía no significa pagado. [1] [4]
Un aviso del servicio no equivale a tener fondos en la cartera de destino. Boltz explica que invoice.settled en un swap inverso puede aparecer tras entregar la preimage y liquidar la factura Lightning. El servicio no comprueba si la aplicación de Anna difundió realmente la transacción claim. Por eso hay que verificar la salida de destino, la porción concreta de bitcoin asignada a su cartera, y las confirmaciones necesarias en bloques. Un bloque es un grupo de transacciones añadido a la cadena. Incluir una transacción en un bloque le da su primera confirmación; cada bloque posterior añade otra. Un estado confuso no justifica volver a enviar inmediatamente el mismo pago. [1] [2]
En un swap normal, el bitcoin de Anna puede estar ya bloqueado en la cadena mientras la factura sigue sin pagar. La devolución, refund, requiere entonces una transacción preparada y difundida por su aplicación. Sin cooperación del servicio debe esperar al timelock, la condición temporal acordada. En el sentido inverso, mientras el pago Lightning no se haya liquidado, sus HTLC pendientes pueden cancelarse. Así se libera el saldo sin una transacción refund de Anna en la cadena. Eso no significa que un pago ya liquidado vuelva solo después de revelar la preimage. Importan el sentido y la fase. [1] [3]
Anna compara lo que envía con lo que recibe realmente. La diferencia puede incluir comisiones del servicio, de enrutamiento Lightning y de transacciones en la cadena. Un swap normal fallido puede añadir la comisión de devolución. El tiempo también cuenta: publicar un claim puede revelar la preimage antes de que un bloque lo confirme. La documentación de Loop advierte que, cerca del timeout, el cliente puede elevar por encima del límite inicial la comisión del sweep, la transacción que recoge los fondos. El vínculo criptográfico no promete un intercambio instantáneo, gratuito ni sin riesgos. [5] [6]
Las palabras de recuperación de otra cartera quizá no restauren un swap pendiente. Según la aplicación, hacen falta una clave refund o rescue key y los datos del intercambio, incluida la salida bloqueada y el plazo. Boltz Swap Restore deriva claves de su propia copia y localiza los swaps asociados. Para buscarlos utiliza una xpub, una clave pública extendida: puede revelar el historial, pero no firmar ni gastar por sí sola. Una clave privada es un valor secreto que la aplicación usa para firmar una transacción según las condiciones correspondientes. Estas claves permanecen en el dispositivo. Conviene saber qué restaura la copia y dónde se guarda antes de enviar dinero. [7] [3]
El usuario no debería calcular a mano las condiciones criptográficas, pero la aplicación sí debe verificarlas. No basta con confiar en una dirección recibida de una API, la interfaz con la que los programas intercambian datos. El cliente comprueba red, importes y comisiones, hash, claves y plazos. También debe verificar el script, las reglas para gastar, o su árbol en Taproot, y la dirección derivada de ellos. La factura Lightning debe coincidir con la huella y el importe acordados. Un mecanismo sólido no corrige un programa que envía fondos a otro lugar. [2]
Con Taproot, las partes pueden usar MuSig2 para producir una firma conjunta. Esta vía key-path puede costar menos y no necesita publicar las condiciones del swap. La aplicación también necesita la vía script-path, que aplica directamente esas condiciones cuando la contraparte no coopera: para claim o refund, según el sentido. Si un swap normal falla, un refund firmado por ambas partes puede devolver los fondos antes. Pero si Anna quiere recuperarlos sin la cooperación del servicio, debe esperar hasta que el timelock acordado permita la devolución. Mostrar menos datos en la cadena tampoco hace anónimo el intercambio frente al servicio que lo organiza. [3] [4]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CLTV. También enlazan con esta entrada Liquidez de Lightning, Inbound Liquidity, Boltz, Lightning Service Provider.