Haz un pago Lightning y compáralo con on-chain
Vas a crear una solicitud de pago Lightning, pagarla desde otra wallet y comprobar qué información cambia respecto a una transacción on-chain. El objetivo no es aprender una app concreta, sino entender qué significa pagar fuera de la cadena sin perder la capacidad de verificar qué ha ocurrido.
🐥 ¿Partes de cero? Abre esta introducción
Qué es Lightning antes de hacer un pago
Lightning es una red de pagos construida sobre Bitcoin que permite mover valor sin registrar cada pago individual como una nueva transacción on-chain. Para esta práctica necesitas una wallet compatible con Lightning que pueda crear una solicitud de pago y otra desde la que puedas pagarla.
🐥 Invoice, canal y liquidez: vocabulario mínimo
Una invoice es una solicitud de pago Lightning: no es una dirección on-chain. Los pagos viajan a través de canales Lightning. La capacidad disponible para enviar o recibir se suele describir como liquidez. No necesitas dominar todavía cómo se enruta un pago; en esta práctica basta con distinguir qué puedes comprobar en Lightning y qué información ya no aparece como una transacción on-chain por cada pago.
Necesitas dos extremos del pago
Lo más didáctico es controlar tanto la wallet que paga como la que recibe. Pueden ser dos wallets tuyas o una wallet tuya y otra de una persona de confianza. Para esta práctica utiliza una cantidad pequeña.
Antes de empezar, identifica si las wallets que utilizas son autocustodia, custodia de terceros o un modelo híbrido. La experiencia visual puede parecer similar aunque el control real sobre los fondos sea distinto.
Comprueba que ambas wallets pueden usar Lightning
Haz esto
Abre las dos wallets y comprueba que una puede recibir por Lightning y la otra dispone de saldo utilizable para pagar.
saldo para enviar ⚡ Wallet B
capacidad para recibir
No basta con que ambas aplicaciones “soporten Bitcoin”. Deben poder enviar y recibir mediante Lightning en el contexto concreto de esta prueba.
🐥 ¿Por qué una wallet puede tener bitcoin y no poder recibir Lightning?
Porque Lightning introduce estado y liquidez en canales. Dependiendo del diseño de la wallet, recibir puede requerir capacidad entrante, mecanismos automáticos de liquidez o intervención de un proveedor.
Crea una solicitud de pago
Haz esto
En la wallet receptora, crea una solicitud por una cantidad pequeña. Para la práctica nos interesa obtener una invoice Lightning concreta que podamos inspeccionar y pagar.
🐥 ¿Una invoice es como una dirección Bitcoin?
No exactamente. Una invoice Lightning suele representar una solicitud de pago concreta y puede incorporar importe, expiración y otros datos necesarios para el pago. No conviene pensar en ella como una dirección on-chain permanente.
🐥 ¿Cómo reconozco una invoice a simple vista?
Si copias la invoice como texto, verás una cadena larga que empieza por lnbc en la red principal (en redes de prueba, por ejemplo, lntb). Una dirección on-chain moderna empieza en cambio por bc1.
Dentro de la invoice van codificados el importe, la caducidad y un payment hash que identifica este pago concreto. Por eso una invoice se usa una sola vez: después de pagada, no debe reutilizarse.
Revisa qué estás a punto de pagar
Haz esto
Escanea o pega la invoice en la wallet pagadora, pero no confirmes todavía. Comprueba el importe y cualquier información que la wallet pueda decodificar.
El importe que muestra la wallet pagadora debe coincidir con la solicitud creada en la receptora.
🐥 ¿Y si uso una Lightning Address?
Una Lightning Address puede simplificar la experiencia, pero normalmente hay mecanismos adicionales que terminan proporcionando los datos de pago que la wallet necesita. Para esta práctica usamos una invoice explícita porque permite observar mejor el mecanismo.
Si quieres ver las diferencias con calma, lee invoice Lightning, Lightning Address y QR: no son lo mismo.
Autoriza el pago y observa cómo se enruta
Haz esto
Confirma el pago desde la wallet A. Durante unos instantes la aplicación puede mostrar que el pago está en camino mientras intenta encontrar y completar una ruta hasta el receptor.
🐥 ¿No tener confirmaciones significa que el pago no es definitivo?
Lightning no utiliza confirmaciones de bloques para cada pago. El pago actualiza el estado de los canales y utiliza mecanismos criptográficos distintos. La seguridad final sigue anclada a Bitcoin porque los canales pueden resolverse on-chain si es necesario.
Ojo: eso solo te protege a ti si los canales son tuyos. En una wallet custodial, como la que usamos para pagar en este ejemplo, los canales son del proveedor y tu saldo es una cuenta en su sistema: dependes de que cumpla.
Comprueba el resultado en ambos extremos
Haz esto
Abre el detalle del pago en las dos wallets. Una debe mostrar el pago enviado y la otra la recepción correspondiente.
La invoice queda satisfecha por el importe solicitado. En nuestra prueba, el pagador soportó además una cuota de 4 sats para mover un pago de 1 sat.
🐥 ¿La comisión llega al receptor?
No. El receptor recibe el importe del pago; las comisiones de enrutamiento compensan a los nodos intermedios que aportan liquidez y encaminan el pago.
🐥 ¿4 sats de comisión por un pago de 1 sat no es muchísimo?
En porcentaje, sí, pero no es representativo. Las comisiones de Lightning suelen tener una parte fija por cada salto de la ruta y una parte proporcional al importe. En un pago diminuto la parte fija lo domina todo; con importes normales la comisión suele ser una fracción pequeña del pago.
Además, una wallet custodial puede aplicar su propia tarifa mínima. Por eso no conviene sacar conclusiones sobre el coste de Lightning a partir de un pago de 1 sat.
Entiende qué significa que el pago haya encontrado una ruta
Haz esto
Piensa en el pago como un desplazamiento de capacidad a través de uno o varios canales. En nuestra prueba la wallet mostró una cuota de 4 sats: no es una comisión minera, porque no se ha creado ninguna transacción on-chain. En una wallet custodial como la del ejemplo, esa cifra la fija el proveedor y puede incluir su propio margen además del coste real de la ruta.
El pago cambia balances dentro de canales. No crea necesariamente una nueva transacción on-chain cada vez que alguien paga.
🐥 ¿Qué puede hacer que un pago falle?
Entre otras causas, puede no existir una ruta con liquidez suficiente, la invoice puede haber expirado o la wallet puede imponer límites. Lightning necesita liquidez en la dirección adecuada, no solo “saldo total”.
Compáralo con el envío on-chain de la Práctica 03
Haz esto
Repasa qué elementos necesitábamos observar en una transacción on-chain y cuáles no aparecen de la misma forma en este pago Lightning.
TXID pública, inputs, outputs, bloques ≠ Lightning
invoice, ruta, estado de canales
No deberías poder buscar en un explorador público una “TXID on-chain del pago Lightning” equivalente a la que viste en las prácticas anteriores, porque ese pago individual no se publica como una nueva transacción en la blockchain.
👁️ ¿Significa eso que Lightning es totalmente privado?
No. Lightning cambia la superficie de información y evita publicar cada pago completo en la blockchain, pero existen otros metadatos, observaciones de red y dependencias de la wallet o proveedor que pueden afectar a la privacidad.
Separa lo que has comprobado de lo que la app te abstrae
Haz esto
Revisa qué evidencias te da tu wallet: importe, estado pagado, fee, invoice y, si la aplicación lo expone, el payment hash y la preimagen del pago. Busca en el detalle del pago de la wallet pagadora o de la receptora.
La invoice lleva dentro un payment hash. Cuando el pago se completa, el pagador recibe la preimagen: un secreto que solo conocía el receptor y cuyo hash coincide exactamente con ese payment hash. Tener la preimagen demuestra criptográficamente que la invoice se pagó.
🐥 ¿Por qué la preimagen sirve como recibo?
Porque el receptor solo la revela al cobrar, y cada salto de la ruta la necesita para cobrar a su vez. Si el pago no se completa, la preimagen no llega al pagador. Algunas wallets la muestran como “preimage” o “proof of payment”; otras la ocultan. Si la tuya no la enseña, es una de las cosas que la aplicación te está abstrayendo.
Que una solicitud concreta fue pagada y recibida sin esperar confirmaciones de bloques, que la operación no apareció como una nueva transacción pública on-chain y, si tu wallet la muestra, que tienes la preimagen como prueba del pago.
🐥 ¿Qué depende de la wallet que estoy usando?
Mucho de lo que ves: cómo gestiona canales, swaps, liquidez, backups, rutas, fees o custodia. Dos wallets pueden ofrecer una experiencia parecida mientras utilizan arquitecturas muy distintas por debajo.
¿Puedes explicar qué cambió respecto a on-chain?
La prueba termina cuando puedes explicar el pago sin recurrir únicamente a “fue instantáneo”.
-
1
¿Qué pagaste?
Una invoice Lightning concreta por un importe determinado.
-
2
¿Esperaste un bloque?
No. El pago se resolvió actualizando estado dentro de Lightning.
-
3
¿Apareció una TXID pública nueva?
No como equivalente directo del pago individual Lightning.
-
4
¿Qué necesitó la red?
Una ruta con liquidez suficiente entre pagador y receptor. Nuestra wallet cobró además una cuota de 4 sats, fijada por el proveedor.
-
5
¿Cómo demuestras que pagaste?
Con la preimagen: su hash coincide con el payment hash de la invoice.
💡 Qué ha pasado realmente por debajo
En lugar de crear una nueva transacción Bitcoin pública para este pago, Lightning ha actualizado saldos y compromisos dentro de canales. Los participantes pueden encadenar varios canales para formar una ruta entre pagador y receptor.
La blockchain sigue siendo la capa de resolución final del sistema, pero no necesita registrar cada pago Lightning individual.
Lightning cambia cómo se mueve el valor sin sustituir la base de Bitcoin
Ya puedes distinguir un pago on-chain de un pago Lightning por el tipo de evidencia, liquidación, comisiones y visibilidad pública que deja cada uno.
Haz otro pago y compara sus fees
Repite con otro importe pequeño y anota importe, fee y tiempo de liquidación. No busques una regla universal a partir de dos pagos: observa cómo puede variar la ruta y el coste.
Lightning introduce un conjunto distinto de problemas
On-chain vs Lightning
Compara cuándo tiene sentido cada mecanismo y qué compromisos introduce.
Leer →Qué es un canal Lightning
Entiende dónde viven realmente los saldos y por qué los canales importan.
Leer →Liquidez entrante y saliente
Descubre por qué poder enviar y poder recibir son capacidades diferentes.
Leer →Ya has observado, recibido, enviado, recuperado y pagado por Lightning
Estas cinco prácticas forman un primer laboratorio de Bitcoin: empiezan leyendo una transacción pública y terminan comparando dos formas distintas de mover valor.
Volver a Prácticas guiadas →
Hay más piezas que encajan con esta
Continúa por contenidos relacionados con el tema que acabas de estudiar.
Práctica de Coin Control sin enviar bitcoinPrivacidad on-chain
Practica PSBT: revisa una propuesta antes de autorizarWallets y claves
Comprueba una descarga y detecta un archivo modificadoVerificación
Qué comprobar antes de enviar un pago con BitcoinWallets y pagos Lightning
Invoice Lightning, Lightning Address y QR: no son lo mismoWallets y pagos Lightning
Reto final: comprueba un cobro Bitcoin de principio a finTutoriales
Cómo solicitar y realizar una devolución de un pago BitcoinTutoriales
Crea una wallet Bitcoin de solo lectura y comprueba sus límitesWallets y claves
Cómo revisar una selección de UTXO en Sparrow sin firmarPrivacidad on-chain