La red Lightning es una segunda capa construida sobre Bitcoin: una forma de enviar bitcoins en segundos, con comisiones pequeñas, sin esperar a que cada pago se escriba en un bloque. Si seguiste los cursos 1 a 3, ya sabes cómo funcionan las transacciones de Bitcoin en la capa base. Esta lección explica cómo Lightning saca la mayoría de los pagos de esa capa sin dejar de depender de ella para su seguridad.
Lightning no reemplaza la blockchain de Bitcoin. Funciona a su lado. Piensa en la cuenta de un bar: la abres, pides bebidas toda la noche y pagas una vez al final en lugar de pasar la tarjeta por cada bebida. En Lightning, abrir la cuenta es una transacción on-chain que bloquea unos bitcoins, cada ronda es un saldo nuevo que firman ambas partes y pagar la cuenta es una transacción de cierre, con una comisión on-chain.
¿Qué es la red Lightning?
La red Lightning es una red de canales de pago: saldos compartidos entre dos partes, cada uno respaldado por bitcoins bloqueados en la blockchain. Joseph Poon y Thaddeus Dryja la describieron en un artículo fechado en enero de 2016, y su primer software para la red principal de Bitcoin apareció en 2018. Su objetivo es que la gente pueda pagarse muchas veces y recurrir a la blockchain solo de vez en cuando, sin entregar sus bitcoins a una empresa.
Se apoya en cuatro componentes, explicados en esta lección:
- Una dirección compartida (multifirma 2 de 2): las dos partes bloquean bitcoins en una dirección que necesita las firmas de ambas para gastar.
- Transacciones de compromiso: transacciones firmadas pero sin publicar que registran el reparto actual del canal. Cualquiera puede publicar la suya cuando quiera para cobrar su parte on-chain.
- Claves de revocación: una penalización que hace que publicar un reparto antiguo y desactualizado salga perdiendo.
- Contratos con bloqueo por hash y tiempo (HTLC): pagos condicionales que permiten pasar un pago por varios canales sin que nadie en medio pueda quedárselo.
El resultado: dos partes pueden pagarse miles de veces y solo hacen falta dos transacciones on-chain, una para abrir el canal y otra para cerrarlo.
Por qué Bitcoin necesita la red Lightning
Bitcoin añade un bloque aproximadamente cada diez minutos, y cada bloque tiene un límite de tamaño (4 millones de «unidades de peso», fijado en BIP 141). En octubre de 2026, eso suponía unas 5000 transacciones por bloque y unas 720 000 al día, o alrededor de 8 transacciones por segundo para todo el mundo (blockchain.com). El límite es deliberado: cada nodo completo comprueba cada transacción, y los bloques pequeños hacen que usar un nodo siga siendo asequible para la gente corriente.
Cuando más personas quieren espacio del que cabe, compiten mediante comisiones (la lección de comisiones de transacción del curso 3 explica cómo). La mayoría del tiempo son bajas: en octubre de 2026, el promedio estaba bastante por debajo de un dólar por transacción. Pero los días de más actividad se disparan. Según los datos diarios de blockchain.com, la comisión media fue de unos US$ 56 el 22 de diciembre de 2017 y unos US$ 128 el 20 de abril de 2024. Pagar un café on-chain en un día así no tiene sentido.
Lightning reparte el trabajo. La blockchain se convierte en la capa de liquidación, para abrir y cerrar canales y hacer transferencias grandes. Lightning se convierte en la capa de pagos para cantidades cotidianas. Los pagos de un canal no necesitan ningún bloque, así que su número no está limitado por el espacio en los bloques, sino por cuántos bitcoins hay en los canales y si se encuentra una ruta.
Cómo funciona la red Lightning
Canales de pago
Un canal de pago es un saldo privado entre dos partes. Ambas bloquean bitcoins en una dirección 2 de 2 de la blockchain. La cantidad bloqueada es la capacidad del canal: lo máximo que puede haber en uno de sus lados.
Una vez abierto el canal, las dos partes pueden pasar bitcoins de un lado a otro tantas veces como quieran. Ninguna actualización toca la blockchain. Cada una es un acuerdo nuevo, firmado por ambas, sobre cómo se reparten los fondos bloqueados.
Por ejemplo, Alice y Bob abren un canal con 0,1 BTC de capacidad. Alice lo financió, así que el reparto inicial es:
- Saldo de Alice: 0,1 BTC
- Saldo de Bob: 0 BTC
Después de que Alice pague 0,02 BTC a Bob:
- Saldo de Alice: 0,08 BTC
- Saldo de Bob: 0,02 BTC
La actualización ocurrió en un momento. No la procesó ningún minero ni hizo falta ningún bloque. Un pago directo a la otra parte del canal no paga comisión de enrutamiento.
Abrir un canal
Abrir un canal requiere una transacción on-chain, la transacción de financiación, que envía bitcoins a la dirección compartida 2 de 2. Antes de publicarla, las dos partes intercambian claves y firman las primeras transacciones de compromiso. El orden importa: si la otra parte desaparece en cuanto se abre el canal, todavía puedes publicar tu transacción de compromiso y recuperar tu dinero.
La transacción de financiación debe confirmarse antes de poder usar el canal. Cuántas confirmaciones depende del software. LND, por ejemplo, pide entre 3 y 6 según el tamaño del canal (configuración de ejemplo de LND). Este es el único momento en que esperas a la blockchain.
Transacciones off-chain
Cada pago dentro del canal reemplaza el reparto antiguo por uno nuevo. Ambas partes firman una nueva transacción de compromiso con los saldos nuevos, y la antigua se cancela mediante revocación:
- Alice quiere pagar 0,01 BTC a Bob.
- Ambos firman nuevas transacciones de compromiso con los saldos nuevos.
- Alice da a Bob una clave de revocación de su anterior transacción de compromiso.
- Bob da a Alice una clave de revocación de la suya anterior.
- Si Alice publica después el reparto antiguo, el que le daba más, Bob puede usar la clave de revocación de Alice para reclamar todos los fondos del canal como penalización.
Gracias a esa penalización no tienes que fiarte de la otra parte: quien hace trampa se arriesga a perder todo lo que hay en el canal.
¿Quién vigila las trampas?
La penalización solo funciona si alguien detecta a tiempo la transacción antigua en la blockchain. Cuando una parte publica una transacción de compromiso, sus propios fondos quedan bloqueados durante un período de espera, así que la otra tiene un plazo para responder. Alguien debe vigilar durante ese plazo: tu propio software Lightning, que lo hace mientras funciona conectado a internet, o una watchtower, un servicio separado que observa la blockchain por ti y publica la penalización si hace falta.
Por eso se indica a quienes operan nodos que los mantengan conectados. En LND, el software de nodo más común, el cliente de watchtower está apagado hasta que lo actives. Nuestra lección sobre Copias de seguridad Lightning y watchtowers explica cuándo necesitas una, y la lección 4.8 enseña a activarla.
Cerrar un canal
Hay dos formas de cerrar un canal:
Cierre cooperativo: ambas partes acuerdan y firman una transacción de cierre que paga a cada una su último saldo. Es la forma barata, rápida y habitual.
Cierre forzoso: una parte publica por sí sola su última transacción de compromiso, normalmente porque la otra no está conectada o no responde. Cuesta más en comisiones on-chain, y quien cierra debe esperar un número fijado de bloques antes de gastar su parte. Es el período de espera explicado arriba.
En ambos casos, los saldos finales quedan firmes on-chain y los bitcoins vuelven a direcciones normales de un solo dueño. Un cierre forzoso suele necesitar dos o más transacciones on-chain en lugar de una, así que cuesta cerca del doble en comisiones de minería o más. Nuestra lección sobre Copias de seguridad Lightning y watchtowers calcula en sats lo que cuestan abrir y cada forma de cerrar.
Enrutar pagos por la red Lightning
No necesitas un canal con cada persona a la que pagas. Un pago puede enrutarse por canales de otros, saltando de nodo en nodo hasta quien lo recibe.
Supón que Alice quiere pagar a Dave. Alice tiene un canal con Bob, Bob con Carol y Carol con Dave. El pago puede ir Alice → Bob → Carol → Dave, normalmente en pocos segundos.
Primero, dos términos. Un hash es una huella de unos datos: fácil de calcular a partir de ellos y prácticamente imposible de invertir. La preimagen son los datos originales detrás del hash. Imagina un candado que solo abre una clave: Dave entrega el candado (el hash) y guarda la clave (la preimagen).
El enrutamiento usa contratos con bloqueo por hash y tiempo (HTLC), pagos que solo se abren con la clave y vencen tras un plazo:
- Dave inventa un secreto aleatorio (la preimagen) y pone su hash en la factura que da a Alice.
- Alice ofrece a Bob un HTLC: «recibes X sats si me muestras la preimagen de este hash antes de, digamos, 60 bloques. Si no, el dinero vuelve a mí».
- Bob ofrece a Carol un HTLC parecido con un plazo algo menor.
- Carol ofrece uno a Dave con un plazo todavía menor.
- Dave revela la preimagen a Carol y cobra su pago.
- Carol usa la misma preimagen para cobrar su pago de Bob.
- Bob la usa para cobrar su pago de Alice.
El pago es atómico: o se completan todos los saltos o ninguno. Nadie en medio puede quedarse el dinero porque solo puede cobrar del salto anterior revelando la preimagen, que solo conoce cuando se paga el siguiente. Los plazos decrecientes dan a cada nodo tiempo para cobrar después de pagar.
Para la privacidad, Lightning usa enrutamiento cebolla, parecido en idea a Tor: cada nodo solo conoce el salto anterior y el siguiente. Bob sabe que recibió algo de Alice y debe pasarlo a Carol, pero no que Dave sea el destinatario final. Los nodos del camino sí ven más o menos cuánto se paga. La lección 4.2 explica por qué.
Comisiones de la red Lightning
Los nodos de enrutamiento cobran una comisión por reenviar pagos, que les compensa por dejar bitcoins en los canales y seguir conectados. Cada nodo fija dos cifras:
- Comisión base: una cantidad fija por pago reenviado, fijada en milésimas de satoshi (un satoshi, o sat, es una cienmillonésima de bitcoin).
- Tasa de comisión: un porcentaje de la cantidad, escrito en partes por millón (ppm). 100 ppm es el 0,01 %.
Un ejemplo con cifras reales: en la instantánea más reciente de la red pública de mempool.space (30 de agosto de 2026), el nodo mediano cobraba una comisión base de 0,5 sat y una tasa de 100 ppm. Un pago de 10 000 sats que pasa por dos nodos de enrutamiento paga a cada uno 0,5 + 1 = 1,5 sats, unos 3 sats en total. Un pago de 100 000 sats por la misma ruta paga unos 21 sats. La tasa media de esa instantánea era de 824 ppm, así que algunas rutas cuestan varias veces más (estadísticas Lightning de mempool.space).
Algunas billeteras cobran un precio total en su lugar. Phoenix, la billetera para principiantes que recomienda este curso, cobra el 0,4 % + 4 sat por cada pago Lightning que envías, enrutamiento incluido (preguntas frecuentes de Phoenix): 44 sats en un pago de 10 000 sats. Phoenix entrega cada pago al nodo de ACINQ, que busca el resto de la ruta y paga esas comisiones con ese cobro, así que no sumas ambos. Abrir y cerrar canales también cuesta comisiones on-chain, que cambian con la demanda de espacio en los bloques.
Nuestra guía completa de comisiones de la red Lightning tiene más escenarios y formas de reducir las comisiones.
Capacidad y crecimiento de la red Lightning
Lightning funciona en la red principal de Bitcoin desde 2018. La instantánea de mempool.space del 30 de agosto de 2026 contaba:
- Nodos públicos: unos 16 200
- Canales públicos: unos 32 700
- Bitcoins en canales públicos: unos 3800 BTC
- Canal mediano: unos 2 millones de sats
Estas cifras solo cubren la red pública. Muchos canales, incluida la mayoría de los de billeteras de teléfono, son privados y no pueden contarse. Lo que indican: unos miles de bitcoins repartidos en decenas de miles de canales explican por qué los pagos pequeños y medianos encuentran ruta fácilmente y los muy grandes pueden tener dificultades.
Probarás a enviar y recibir en la lección 4.4.
Limitaciones de la red Lightning
Lightning tiene inconvenientes que todo usuario debería entender:
- Recibir exige liquidez de entrada: solo puedes recibir, como mucho, lo que las otras partes de tus canales tengan de su lado. Esto confunde a muchos principiantes y se explica en la lección 4.2.
- Estar conectado: tu billetera o nodo debe estar conectado para recibir un pago, a diferencia de una dirección on-chain, que recibe esté abierta la billetera o no. También tiene que conectarse con regularidad para vigilar las trampas.
- Gestión de canales: mantener útiles los canales en ambas direcciones requiere atención y a veces cuesta dinero. Billeteras como Phoenix lo hacen por ti. En tu nodo es tarea tuya (lo explica la lección 4.8).
- Pagos grandes: los pagos muy grandes pueden no encontrar una ruta con liquidez suficiente.
- Complejidad y copias de seguridad: Lightning tiene más componentes que Bitcoin on-chain, y respaldar un canal no es tan sencillo como anotar una semilla. Nuestra lección sobre Copias de seguridad Lightning y watchtowers explica qué guardar.
Los desarrolladores trabajan en ello. Splicing permite cambiar el tamaño de un canal sin cerrarlo, y la búsqueda de rutas sigue mejorando.
Ideas principales
- Lightning es una segunda capa sobre Bitcoin: los pagos se mueven dentro de canales respaldados por bitcoins bloqueados en la blockchain
- Un canal necesita una transacción on-chain para abrirse y otra para cerrarse. Entre ambas, todo son acuerdos firmados entre las dos partes
- Las claves de revocación hacen que publicar un saldo antiguo salga perdiendo, pero solo si tu nodo o una watchtower observa la blockchain a tiempo
- Los HTLC permiten cruzar varios canales, de modo que se completan todos los saltos o ninguno
- Las comisiones de enrutamiento son pequeñas: con la política mediana de agosto de 2026, unos 3 sats por un pago de 10 000 sats que pasa por dos saltos. Algunas billeteras cobran un precio total en su lugar (Phoenix: 0,4 % + 4 sat por pago, enrutamiento incluido)
- Los canales se cierran de forma cooperativa (barata y rápida) o con cierre forzoso (más caro y con período de espera)
Preguntas frecuentes
¿Es segura la red Lightning?
Su diseño permite recuperar tu dinero sin confiar en la otra parte del canal, pero esa protección tiene condiciones. Tu nodo o una watchtower debe ver un intento de trampa antes de que termine el período de espera. Un cierre forzoso en un período de comisiones on-chain altas puede consumir gran parte de un saldo pequeño. Necesitas las copias de seguridad adecuadas (nuestra lección sobre Copias de seguridad Lightning y watchtowers explica cuáles). Y, como cualquier software, las implementaciones de Lightning tienen errores: revisa nuestros avisos de seguridad y mantén actualizada la billetera. Las billeteras Lightning bien probadas gestionan casi todo eso por ti.
¿Cuánto cuesta usar la red Lightning?
Unos pocos sats de enrutamiento en pagos pequeños (como en el ejemplo anterior), o el precio propio de tu billetera si cobra uno en su lugar (Phoenix: 0,4 % + 4 sat por pago enviado, enrutamiento incluido), más comisiones on-chain cuando se abre o cierra un canal. La lección 4.3 detalla lo que cuesta un primer depósito en Phoenix.
¿Necesito ejecutar un nodo para usar la red Lightning?
No. Billeteras como Phoenix y Zeus ejecutan pequeños nodos Lightning en tu teléfono. Tu propio nodo completo te da más control y privacidad, y la opción de enrutar pagos de otros. La lección 4.5 explica los motivos con más detalle.
¿Puede la red Lightning gestionar pagos grandes?
Funciona mejor para pagos pequeños y medianos. Los grandes pueden no encontrar una ruta con liquidez suficiente en cada salto. Los pagos por múltiples rutas (MPP) ayudan al dividir un pago entre varias. Para transferencias muy grandes, una transacción on-chain suele ser mejor.
¿Qué pasa si la otra parte del canal se desconecta?
Puedes forzar el cierre publicando tu última transacción de compromiso. Tu parte vuelve on-chain tras un período de espera que el software de la otra parte fijó al abrir el canal. Con los valores por defecto de LND, va de 144 bloques (alrededor de un día) para canales de menos de unos 1,2 millones de sats a 2016 bloques (unas dos semanas) para los mayores (configuración de ejemplo de LND). En Phoenix son 720 bloques, unos cinco días, y ACINQ dice que solo se fuerce el cierre como último recurso porque «se aplican comisiones altas» (preguntas frecuentes de Phoenix). Nunca necesitas la colaboración de la otra parte para recuperar tus fondos, pero sí pagas comisiones on-chain y esperas.
Comprueba lo que entendiste
1. Alice y Bob tienen un canal. Alice publica una transacción de compromiso antigua que le da más de lo que tiene ahora. ¿Qué la detiene y qué debe cumplirse para que funcione?
Respuesta
Bob tiene la clave de revocación que Alice le dio al reemplazar ese saldo antiguo. Con ella puede reclamar todos los fondos del canal como penalización. Pero el nodo de Bob o una watchtower que trabaje para él debe detectar la transacción de Alice en la blockchain antes de que termine el período de espera de Alice. Si nadie vigila, no puede aplicarse la penalización.
2. En un pago Alice → Bob → Carol → Dave, ¿por qué Bob no puede quedarse el dinero de Alice sin pagar a Carol?
Respuesta
El pago de Alice a Bob solo se abre con la preimagen, el secreto detrás del hash de la factura de Dave. Bob solo lo conoce cuando Carol lo revela para cobrar su pago de él, y Carol solo lo conoce cuando se paga a Dave. Así que Bob solo puede cobrar de Alice después de que pase el pago. Si nunca pasa, el HTLC de Alice vence y su dinero vuelve a ella.
3. Envías un pago de 100 000 sats por dos nodos que cobran cada uno 0,5 sat más 100 ppm. ¿Cuánto pagas en comisiones de enrutamiento, más o menos?
Respuesta
Cada nodo cobra 0,5 sat más 100 millonésimas de 100 000 sats (10 sats), así que son unos 10,5 sats por nodo y unos 21 sats en total. Una billetera como Phoenix cobra su propio precio total en su lugar (0,4 % + 4 sat, enrutamiento incluido), que en este pago sería de 404 sats.