Um Point Time Locked Contract combina um bloqueio por ponto com uma via temporal de reembolso: completar uma adaptor signature revela o escalar correspondente, usado pelo participante anterior para completar a própria assinatura, enquanto os fundos podem ser recuperados após o timelock; é um componente de protocolo, não um tipo padrão de pagamento Lightning hoje.
Um HTLC condiciona o caminho de sucesso ao conhecimento da preimage de um hash comum; um PTLC usa o ponto T = t·G e uma adaptor signature que só pode ser completada com o escalar t. O caminho temporal permanece: se a liquidação falhar, o emissor recupera os fundos após o timeout. [1]
O destinatário escolhe um escalar secreto e publica o ponto correspondente. Cada par de nós vizinhos prepara assinaturas incompletas ligadas ao seu bloqueio por ponto; quando o destinatário completa a assinatura final, a diferença entre o adaptador e a assinatura válida revela o escalar e permite liquidar o percurso para trás. [1]
O emissor pode adicionar escalares aleatórios diferentes em cada salto, e os nós subtraem progressivamente os respetivos pontos. Dois nós de roteamento em conluio deixam de ver o mesmo payment hash de um HTLC convencional; ainda existe correlação por valor, timing, expiração ou topologia. [4]
BIP 340 dá às assinaturas Schnorr uma equação linear que torna os adaptadores mais fáceis de compor do que com ECDSA. Com uma chave agregada, um gasto on-chain bem-sucedido pode parecer uma assinatura comum, mas a economia real depende da construção do canal, do protocolo multisignature e da via de emergência. [2]
A segurança depende de mais do que o ponto e o timelock. A implementação deve verificar o adaptador, vincular corretamente assinatura, mensagem e chave, proteger nonces, extrair o escalar com segurança, preservar o reembolso e tratar a interrupção da contraparte; um erro pode expor uma chave ou perder fundos. [1]
O BOLT #2 básico atual ainda descreve update_add_htlc, update_fulfill_htlc e htlc_signature. Assim, PTLC não é uma função interoperável da Lightning Network comum apenas porque Taproot e BIP 340 estão ativos no Bitcoin; são necessários mensagens, estados de canal e implementações compatíveis. [3]
A discussão de programadores de 2025 aponta a falta de ferramentas maduras e padronizadas para adaptor signatures com MuSig2 e adaptadores Schnorr autónomos nas bibliotecas comuns. PTLC é uma proposta tecnicamente desenvolvida, mas o estado público das ferramentas e especificações impede afirmar uma implantação ampla. [5]
PTLC pode melhorar a descorrelação de pagamentos roteados, proof of payment, pagamentos atómicos por múltiplos caminhos e alguns swaps. Não resolve sozinho disponibilidade do canal, liquidez, perda de estado, timing malicioso nem anonimato completo; o benefício deve ser avaliado com onion routing e o desenho do canal. [4]
Para ter uma visão mais completa, leia este verbete junto com HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. Também há referências a este verbete em Trampoline Routing.
01A Lightning Network comum usa hoje PTLC em vez de HTLC?+
Não como base interoperável comum. As especificações BOLT atuais ainda definem mensagens e assinaturas HTLC. PTLC exige ferramentas criptográficas, mensagens, transições de estado e acordo entre implementações; a ativação de Taproot não realizou sozinha essa migração.
02Por que um PTLC é mais privado que um HTLC?+
Vários saltos HTLC podem carregar o mesmo payment hash, dando a nós em conluio um valor direto de correlação. PTLC permite que cada salto altere o bloqueio ao adicionar um ponto local. Valor, timing, expiração e posição na rede ainda podem ligar o pagamento.