Un Point Time Locked Contract combina un bloqueo por punto con una vía de reembolso temporal: completar una adaptor signature revela el escalar correspondiente, que el participante anterior usa para completar su propia firma, mientras que los fondos pueden recuperarse al vencer el timelock; es un componente de protocolo, no un tipo estándar de pago Lightning actual.
Un HTLC condiciona la rama exitosa al conocimiento de la preimagen de un hash compartido; un PTLC usa en su lugar un punto T = t·G y una adaptor signature que solo puede completarse con el escalar t. La rama temporal permanece: si el pago no se liquida, el emisor recupera los fondos después del timeout. [1]
El receptor elige un escalar secreto y publica el punto correspondiente. Cada par de nodos vecinos prepara firmas incompletas vinculadas a su bloqueo por punto; cuando el receptor completa la última firma, la diferencia entre el adaptador y la firma válida revela el escalar y permite liquidar hacia atrás por la ruta. [1]
El emisor puede sumar escalares aleatorios distintos para cada salto y los nodos restan progresivamente sus puntos. Dos nodos de enrutamiento que colaboren ya no ven el mismo payment hash como en un HTLC convencional; aún queda correlación por importe, tiempo, expiración o topología. [4]
BIP 340 da a las firmas Schnorr una ecuación lineal que permite componer adaptadores de forma más natural que con ECDSA. Con una clave agregada, un gasto on-chain exitoso puede parecer una firma ordinaria, pero el ahorro real depende de la construcción del canal, el protocolo multisignature y la vía de emergencia. [2]
La seguridad no depende solo del punto y del timelock. La implementación debe verificar el adaptador, vincular correctamente la firma al mensaje y la clave, proteger los nonces, extraer el escalar con seguridad, conservar el reembolso y gestionar la interrupción de la contraparte; un error puede filtrar una clave o perder fondos. [1]
El BOLT #2 básico vigente todavía describe update_add_htlc, update_fulfill_htlc y htlc_signature. Por ello no puede afirmarse que PTLC sea una función interoperable de la Lightning Network ordinaria solo porque Taproot y BIP 340 estén activos en Bitcoin; hacen falta mensajes, estados de canal e implementaciones compatibles. [3]
La discusión entre desarrolladores de 2025 señala la falta de herramientas maduras y estandarizadas para adaptor signatures con MuSig2 y para adaptadores Schnorr independientes en las bibliotecas habituales. PTLC es una propuesta técnicamente elaborada, pero el estado público de herramientas y especificaciones impide hablar de despliegue general. [5]
PTLC puede mejorar la descorrelación de pagos enrutados, la prueba de pago, los pagos atómicos por varias rutas y ciertos swaps. No resuelve por sí solo la disponibilidad del canal, la liquidez, la pérdida de estado, el timing malicioso ni el anonimato completo; debe evaluarse junto con onion routing y el diseño del canal. [4]
Para obtener la imagen más completa, lee esta entrada junto con HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. También enlazan con esta entrada Trampoline Routing.
01¿Usa hoy la Lightning Network ordinaria PTLC en lugar de HTLC?+
No como base interoperable común. Las especificaciones BOLT vigentes aún definen mensajes y firmas HTLC. PTLC necesita herramientas criptográficas, mensajes, transiciones de estado y acuerdo entre implementaciones; activar Taproot no realizó por sí solo esa migración.
02¿Por qué un PTLC ofrece más privacidad que un HTLC?+
Varios saltos HTLC pueden llevar el mismo payment hash y dar a nodos colaboradores un dato directo de correlación. PTLC permite que cada salto cambie el bloqueo sumando un punto local. El importe, el tiempo, la expiración y la posición en la red todavía pueden vincular el pago.