Bitcoin Lightning vs. pagos on-chain: comisiones, confirmaciones y canales

Ambas pueden transferir valor denominado en bitcoin, pero usan la capa base de forma distinta. Un pago on-chain crea una transacción que los nodos pueden propagar y los mineros incluir en un bloque. Un pago Lightning intenta recorrer una ruta de canales de pago; cada pago individual no se publica como una transacción propia de Bitcoin.

La diferencia afecta las comisiones, la disponibilidad, la privacidad y las señales que muestra la cartera. Lightning no es otra moneda, y “fuera de la cadena” no significa que el pago carezca de reglas o riesgos. Los participantes usan transacciones de Bitcoin para abrir el canal y liquidar sus saldos si hace falta.

La cartera selecciona salidas disponibles, construye y firma una transacción y la difunde a los nodos de Bitcoin. Los nodos pueden retransmitirla y guardarla en sus propios mempools mientras espera a que un minero la incluya en un bloque. La comisión de red depende del tamaño de la transacción y de la tasa ofrecida, no solo de la cantidad de bitcoin enviada. Consulta la guía de procesamiento de pagos de Bitcoin Developer Guide.

El identificador de transacción permite consultar lo difundido, pero verla no significa que esté confirmada. Una confirmación indica que un bloque la incluye; los bloques posteriores aumentan ese recuento. El servicio receptor o su política de riesgo determina cuántas espera. Ni el intervalo de bloques ni una meta de confirmación garantizan que los fondos estén disponibles en un minuto concreto.

Quien recibe puede compartir una factura Lightning con una solicitud de pago, a menudo con importe, destino, descripción y caducidad. La cartera que paga la interpreta y busca una ruta con capacidad y límites adecuados. La especificación BOLT 11 de facturas describe los campos de la solicitud; BOLT 7 trata los anuncios de canales y las actualizaciones de rutas.

El pago enrutado usa transferencias condicionales conocidas como HTLC. Cada nodo intermedio recibe el importe y las condiciones de tiempo necesarias para el siguiente tramo; el destinatario final revela el secreto que permite completar el pago. La ruta puede fallar si no hay liquidez en la dirección necesaria, si una actualización está desfasada, se alcanza un límite o un nodo no responde. Un pago Lightning exitoso puede completarse sin esperar un bloque nuevo, pero no se garantiza que todas las facturas puedan pagarse.

Un canal comienza con una transacción de financiación on-chain y tiene una capacidad total. Cuando las partes se pagan entre sí, el saldo cambia sin publicar una transacción de Bitcoin por cada actualización. Lo que una parte puede enviar en ese momento depende del saldo en esa dirección, las reservas, los límites del pago y la ruta elegida. El protocolo de pares BOLT 2 describe parámetros del canal y límites de HTLC.

Un canal con capacidad total suficiente aún puede no tener liquidez saliente para un pago concreto. El destinatario también puede carecer de una ruta entrante útil para ese importe. Abrir un canal, mover liquidez o cerrarlo puede requerir transacciones y comisiones on-chain. BOLT 5 sobre operaciones on-chain explica los cierres cooperativos y unilaterales. La ilustración separa los pagos repetidos del canal de la financiación y el cierre que se liquidan en Bitcoin.

La comisión on-chain paga espacio en los bloques. El total depende del tamaño de la transacción y de la tasa elegida para las condiciones actuales; una transacción más grande puede costar más aunque envíe menos bitcoin. La estimación de una cartera cambia con el mercado y no reserva un sitio en un bloque futuro.

Las tarifas de reenvío Lightning las fijan los operadores de canal y pueden combinar una cantidad base con una parte proporcional. La longitud de la ruta, las políticas, la liquidez y el comportamiento de la cartera afectan el coste. Algunas carteras pueden añadir cargos propios o costes de liquidez. Lightning puede resultar más barato en un caso concreto, pero no siempre es gratis ni más económico que on-chain. Antes de aprobar, compara el importe final, el detalle de cargos y los requisitos de ruta.

Una cartera on-chain puede mostrar estados como difundido, pendiente o confirmado. La cadena de bloques publica transacciones y bloques, y quien recibe puede aplicar el umbral de confirmación adecuado para el importe y el contexto. Una transacción puede tardar más de lo esperado; una estimación de comisión no controla qué eligen los mineros.

En Lightning, la factura queda pagada cuando la ruta termina y la cartera recibe una respuesta de éxito. Ese pago individual no se incluye en un bloque de Bitcoin. Un intento fallido no es una confirmación, y una pantalla incierta no demuestra que sea seguro pagar otra vez. Antes de repetir el envío, comprueba el estado final de la cartera y la factura o el recibo del destinatario.

Los datos on-chain son públicos y pueden analizarse, aunque una dirección no revele automáticamente el nombre de una persona. El enrutamiento cebolla de Lightning busca limitar lo que cada nodo intermediario sabe de la ruta completa, pero no vuelve anónimo todo pago. La especificación BOLT 4 de enrutamiento cebolla y los anuncios públicos de canales de BOLT 7 describen parte de ese modelo.

Las carteras también difieren en quién controla las claves y cómo supervisan, respaldan y recuperan canales. Una cartera autocustodiada y una cuenta Lightning custodiada no implican las mismas tareas ni los mismos riesgos de fallo. La conexión a internet, la disponibilidad de pares, el estado del canal, la recuperación y las condiciones del proveedor pueden importar. La palabra “Lightning” por sí sola no explica la custodia ni cómo se protegen las copias de seguridad.

On-chain puede encajar cuando el destinatario proporciona una dirección de Bitcoin y necesita una transacción que pueda consultar en la cadena. Lightning puede servir para un pago entre carteras compatibles si hay una factura y liquidez suficiente en la ruta. Los pagos pequeños repetidos pueden aprovechar un canal ya abierto, aunque abrir, mantener y cerrar canales conlleva costes y límites.

Antes de enviar, verifica el tipo de pago, la red, el importe, la caducidad de la factura, el destinatario, la comisión mostrada y los límites. No pegues una factura Lightning en el campo de dirección on-chain ni uses una ruta que el destinatario no pidió. Usa una alternativa on-chain solo si la factura y la cartera la admiten expresamente. Para ampliar: comisiones de transacción de Bitcoin, confirmaciones de depósitos y lista de verificación para transferencias cripto.

Fuentes técnicas primarias: Bitcoin Developer Guide: procesamiento de pagos; BOLT 2: protocolo de pares; BOLT 4: enrutamiento cebolla; BOLT 5: transacciones on-chain; BOLT 7: anuncios de rutas; BOLT 11: codificación de facturas.