Cómo hacer el primer pago por Lightning

Con qué se termina

Una billetera Lightning con una cantidad pequeña de bitcoin, un pago enviado contra la factura de otra persona y un pago recibido contra una factura generada por uno mismo. Las dos direcciones, porque enviar funciona a la primera para casi todo el mundo y recibir es donde la gente se traba.

Esta guía es para alguien que ya tiene un poco de bitcoin y nunca usó Lightning, y no supone nada sobre operar un nodo.

Sobre las versiones. Los pasos de abajo se escribieron el 20 de agosto de 2026 a partir de la documentación de cada proyecto y de las especificaciones BOLT, no de las pantallas de una versión concreta. Las interfaces de las billeteras cambian más rápido de lo que cualquier guía puede volver a verificarse, así que cuando un botón de la aplicación se llame distinto de lo que dice acá, conviene confiar en la aplicación y comprobar qué versión se está usando antes de seguir las instrucciones de nadie, incluidas las nuestras.

Antes de empezar

• Una cantidad que no importe perder por completo. Esta es una primera prueba de un sistema desconocido. Ese dinero es matrícula.
• Alguien a quien pagar. Un amigo con billetera Lightning es lo ideal, porque permite enviar en las dos direcciones y comparar lo que vio cada lado.
• Un teléfono o una computadora, y alrededor de una hora, casi toda ella esperando una confirmación en cadena y solo en la ruta de autocustodia.
• Una idea de las comisiones actuales en cadena en esa ruta, porque abrir un canal es una transacción de Bitcoin común que las paga. Ver cómo las comisiones compran espacio de bloque.

La decisión que cambia todos los pasos siguientes

Las billeteras Lightning vienen en dos formas, y la forma decide cómo se fondea, cómo se recibe y qué significa siquiera un backup. Conviene decidir antes de instalar nada.

Una billetera custodial tiene las claves y opera el nodo; uno tiene una cuenta. La documentación de Blink lo dice sin rodeos: "En el Modo Custodial, Blink mantiene los fondos en su nombre y puede ayudar con la recuperación de la cuenta. En el Modo No Custodial (impulsado por el protocolo Spark), usted tiene sus propias claves y Blink no puede acceder, congelar ni recuperar sus fondos."

Una billetera de autocustodia guarda las claves y el estado de los canales en el dispositivo. Phoenix, de ACINQ, es una: "al crear una billetera nueva se genera una frase de recuperación de 12 palabras. Solo usted la tiene." Zeus, "una billetera Bitcoin móvil y una aplicación de gestión de nodos", es otra, y puede ejecutar un nodo embebido o manejar un nodo que uno ya opera.

Las dos son Lightning de verdad. Ninguna es la opción para principiantes y ninguna es la avanzada.

El costo que se está aceptando

Lo custodial le entrega a una empresa la capacidad de congelar, perder o rechazar el saldo, y la de ver cada pago que se hace. A cambio, recibir funciona desde el primer día, no hay nada que respaldar más allá de las credenciales de la cuenta y no hay comisión en cadena para empezar. El modo de falla es la decisión de otro.

La autocustodia significa que nadie puede congelar el saldo y nadie ve el historial de pagos por defecto. A cambio se paga una comisión en cadena para abrir el canal, la primera recepción puede costar más que el monto recibido y las obligaciones de backup son mayores que en una billetera en cadena común. El modo de falla es el error propio. Si tener las claves propias en cadena todavía es nuevo, mejor hacer eso primero y volver después.

Fondear la billetera

Si la elección fue custodial

1. Instalar la aplicación y crear la cuenta.
2. Abrir la pantalla de recepción y elegir la opción en cadena, si la billetera la ofrece.
3. Enviar una cantidad pequeña desde donde esté hoy el bitcoin.
4. Esperar las confirmaciones que exija el proveedor y después comprobar que el saldo se puede gastar por Lightning y no quedó en un saldo en cadena aparte.

Si la elección fue autocustodia

1. Instalar la aplicación y anotar la frase de recuperación en papel, sin conexión, antes de fondear nada.
2. Abrir la pantalla de recepción y tomar la dirección en cadena que da.
3. Enviar una cantidad pequeña y esperar la confirmación. La billetera ahora tiene fondos en cadena, no fondos en Lightning.
4. Dejar que la billetera abra un canal, o abrirlo uno mismo. En cualquier caso es una transacción de Bitcoin que paga comisión, y hasta que confirme no se puede pagar por Lightning.

Pagar una factura

1. Pedir del otro lado una factura por un monto concreto. Es una cadena larga que empieza con lnbc, casi siempre mostrada como código QR. Lo que codifica está en qué es realmente una factura Lightning.
2. Revisar primero el vencimiento. Según BOLT 11, una factura lleva un vencimiento en segundos, con un valor por defecto de 3600, una hora, cuando el campo no está. Una factura vencida no se puede pagar: hay que pedir otra.
3. Escanearla o pegarla en la pantalla de envío de la billetera.
4. Leer el monto y la comisión que se muestran antes de confirmar. La comisión se informa por adelantado porque la billetera elige la ruta antes de enviar nada.
5. Confirmar. Un pago que funciona se liquida en segundos.

Recibir, y el problema del que nadie avisa

Primero el mecanismo, porque el síntoma no tiene sentido sin él. Un canal lo fondea un lado. BOLT 0 describe la posición inicial: los dos participantes "tienen cada uno una transacción de bitcoin que devuelve todo el bitcoin (por ejemplo, 0,1 bitcoin) a una de las partes." Un pago solo mueve ese reparto. Entonces el dinero que se puede recibir por un canal es el que en ese momento está del otro lado, y un canal fondeado por uno mismo arranca sin nada ahí. Eso es la liquidez entrante, y ninguna billetera puede hacerla desaparecer.

1. Abrir la pantalla de recepción e ingresar un monto.
2. Si la billetera es custodial, la factura aparece de inmediato. El nodo del proveedor tiene los canales, y su liquidez entrante es problema suyo.
3. Si es de autocustodia y es la primera recepción, hay que esperar que pidan pagar por la liquidez, o ver un tope sobre cuánto se puede recibir. Phoenix cobra una comisión por aprovisionarla automáticamente y publica el esquema en su FAQ; un nodo propio exige comprar capacidad entrante o gastar hacia afuera primero.
4. Enviar la factura a quien va a pagar, y mirar que se liquide, no que la aplicación apenas la muestre como creada.

Gastar hacia afuera es la forma más barata de ganar capacidad entrante, y por eso el orden de una primera sesión es: fondear, pagar y después recibir.

Verificar que funcionó

1. Comprobar que el lado receptor dice liquidado, no pendiente. Una factura creada no demuestra nada.
2. Devolverlo. Que la otra persona pague, y después devolverle una parte. Un pago en cada dirección es la prueba más chica que ejercita los dos saldos.
3. Mirar los números de capacidad. Después de pagar hacia afuera, una billetera de autocustodia debería mostrar más capacidad de recepción que antes. Si no, el pago no se liquidó.
4. En billeteras de autocustodia, hacer la prueba de restauración en un dispositivo de sobra mientras el saldo sea insignificante, siguiendo la sección de más abajo. No después, con dinero real en el canal.

Cuando un pago falla

Los fallos son normales, y casi nunca son culpa de uno. La billetera rutea por canales de otras personas usando un mapa público que dice cuán grande es cada canal y nunca dice cómo está repartido el saldo adentro. Así que adivina, y a veces adivina mal.

El salto que no puede reenviar devuelve un error a quien envió. BOLT 4 los define; dos vale la pena distinguirlos:

• temporary_channel_failure: "El canal del nodo que procesa no pudo manejar este HTLC, pero puede llegar a manejarlo, o manejar otros, más adelante." Casi siempre el saldo estaba del lado equivocado de ese canal. Reintentar, y reintentar con un monto menor.
• incorrect_or_unknown_payment_details: el destino lo rechazó. La factura está vencida, ya fue pagada o es por otro monto. Hay que pedir una nueva.

Un pago fallido no pierde el dinero. Un pago se liquida a lo largo de toda la ruta o se deshace a lo largo de ella. El único caso que asusta es un pago trabado, cuando un nodo intermedio se cae en medio del intento: el monto queda retenido hasta que pasa el vencimiento en cadena de ese salto, y después vuelve. Hay que esperar, y no pagar la misma factura otra vez desde otra billetera hasta que el primer intento se resuelva.

Backups, y qué cubren exactamente

En una billetera custodial, el backup son las credenciales de la cuenta, y el proveedor igual puede perder o congelar el saldo. No hay frase de recuperación porque no hay claves propias.

En una billetera de autocustodia, la frase de recuperación sola no es toda la historia, porque el estado actual de un canal no se deriva de una semilla como sí se deriva una dirección en cadena. La documentación de recuperación de LND enumera dos elementos necesarios: la semilla cifrada de 24 palabras y el archivo cifrado de Static Channel Backup. Las billeteras de teléfono esconden esto guardando el backup de canales en el dispositivo y muchas veces en la nube del fabricante, pero el requisito de fondo es el mismo.

De ahí salen dos reglas, y las dos le cuestan dinero a la gente con regularidad:

• Nunca correr dos copias de la misma billetera. La guía de seguridad de LND es tajante: "nunca debe usarse la misma semilla en dos nodos distintos, y restaurar desde un SCB no es una migración sino un procedimiento de emergencia." Dos instancias pueden transmitir cada una un estado de canal que la otra ya revocó, y en ese caso la contraparte tiene derecho a llevarse todo el saldo del canal.
• Probar la restauración antes de que la billetera importe. Restaurar en un segundo dispositivo mientras el saldo sea chico, comprobar que los fondos aparecen y después borrar ese dispositivo.

Nada de esto elimina el requisito de estar en línea. Una billetera Lightning que nunca se abre no puede notar que le están cerrando un canal en contra, lo cual es una diferencia real frente a guardar monedas en cadena y la razón por la que un teléfono con un saldo Lightning grande es peor idea de lo que parece. Lo que corre por debajo de estas aplicaciones son cuatro implementaciones distintas, y difieren de maneras que vale la pena conocer.