Canales de pago
Conexiones bidireccionales entre nodos con bitcoin bloqueado. El fundamento técnico de Lightning.
El concepto de canal
Un canal de pago Lightning es una conexión directa entre dos nodos con una cantidad de bitcoin bloqueada que puede moverse instantáneamente entre ellos.
Imagina un tubo entre Alice y Bob con 1 BTC dentro. Ese bitcoin puede deslizarse hacia Alice o hacia Bob infinitas veces, de forma instantánea, sin tocar la blockchain. Solo cuando quieren "cerrar el tubo" y extraer su parte, vuelven a la blockchain.
Abrir un canal
Para abrir un canal, se crea una transacción on-chain que:
- Bloquea bitcoin en una dirección multisig 2-de-2 (ambas partes deben firmar para gastar)
- Define la capacidad total del canal
- Establece el balance inicial de cada lado
Ejemplo: Alice abre canal de 0.1 BTC con Bob.
- Transacción on-chain bloquea 0.1 BTC en multisig
- Balance inicial: Alice 0.1 BTC, Bob 0 BTC
- Capacidad total del canal: 0.1 BTC
Esta transacción se confirma en la blockchain. Ahora el canal está abierto.
Balance local y remoto
El bitcoin dentro del canal se distribuye entre las dos partes:
- Balance local: Lo que está de tu lado (puedes enviarlo)
- Balance remoto: Lo que está del lado del peer (puedes recibirlo)
Si Alice tiene 0.08 BTC local y 0.02 BTC remoto:
- Alice puede enviar hasta 0.08 BTC
- Alice puede recibir hasta 0.02 BTC
La suma siempre es la capacidad total del canal.
Pagos dentro del canal
Cuando Alice paga 0.01 BTC a Bob:
- No hay transacción on-chain
- Ambos actualizan el "estado" del canal: un acuerdo firmado de cómo se distribuye el bitcoin
- Nuevo estado: Alice 0.07 BTC, Bob 0.03 BTC
- El estado anterior se invalida
Este proceso es instantáneo (milisegundos) y casi gratuito.
Pueden hacer miles de actualizaciones sin tocar la blockchain.
Cerrar un canal
Cuando quieres sacar tu bitcoin del canal, lo cierras.
Cierre cooperativo
Ambas partes acuerdan cerrar. Se crea una transacción on-chain que:
- Gasta el multisig del canal
- Envía a cada parte su balance actual
Es rápido y barato. Una sola transacción on-chain.
Cierre forzado (unilateral)
Si una parte no coopera (desaparece, es maliciosa), la otra puede cerrar unilateralmente:
- Publica el último estado válido del canal
- Hay un período de espera (timelock) durante el cual la otra parte puede disputar si el estado publicado no es el más reciente
- Después del timelock, los fondos se liberan
Es más lento y caro (más transacciones, tiempos de espera).
Penalización por fraude
Si Alice intenta cerrar con un estado antiguo donde tenía más bitcoin (fraude):
- Bob puede publicar una "transacción de justicia" durante el período de disputa
- Esta transacción toma TODO el bitcoin del canal como penalización
- Alice pierde todo por intentar hacer trampa
Este mecanismo de penalización hace que el fraude sea económicamente irracional.
Canales y enrutamiento
Un canal conecta dos nodos específicos. Pero Lightning permite pagar a cualquiera, no solo a tus peers directos.
Si Alice tiene canal con Bob, y Bob tiene canal con Carol:
- Alice puede pagar a Carol a través de Bob
- El pago "salta" por los canales intermedios
- Bob cobra una pequeña fee por enrutar
Esto se llama "routing" y es lo que hace Lightning una red, no solo conexiones punto a punto.
Liquidez
El concepto crucial de Lightning:
- Solo puedes enviar lo que tienes en tu lado del canal (balance local)
- Solo puedes recibir lo que hay en el lado remoto (balance remoto)
Si todos tus canales tienen todo el balance de tu lado, no puedes recibir nada (aunque sí enviar).
Gestionar liquidez es el desafío principal de operar un nodo Lightning. Se explora en la siguiente página.
Implicaciones prácticas
Para usuarios con wallet (Phoenix, Breez)
La wallet gestiona canales automáticamente. Cuando necesitas más capacidad, abre o ajusta canales por ti. Pagas fees por esto pero no tienes que entender los detalles.
Para operadores de nodo
Necesitas gestionar activamente:
- Con quién abres canales
- Cuánta capacidad asignas
- Cómo balanceas liquidez
- Cuándo cerrar canales improductivos
Es un trabajo activo, no "set and forget".