Um Hashed Timelock Contract combina uma condição de hash com um bloqueio temporal. O Lightning utiliza payment_hash, um montante e cltv_expiry para cada HTLC. A payment_preimage correspondente permite cumprir as condições de volta ao longo da rota; o timeout permite uma liquidação alternativa. A segurança também depende dos estados confirmados dos canais, das assinaturas e de uma reação atempada.
O destinatário fornece uma payment_preimage de 32 bytes cujo SHA-256 corresponde a payment_hash. O BOLT 11 apresenta o hash no campo p da fatura; o hash, por si só, não revela o segredo. A mesma preimage liga as condições de vários HTLC sucessivos. payment_secret, do campo s, é um dado diferente e não substitui a preimage. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry]
No Lightning, cltv_expiry designa uma altura absoluta de bloco, não um timestamp Unix nem o prazo de validade da fatura BOLT 11 em segundos. Após as condições temporais serem atingidas, o gasto por timeout pode ficar disponível. Contudo, uma preimage válida não deixa automaticamente de funcionar; dois gastos concorrentes da mesma saída não podem ser ambos confirmados numa mesma cadeia válida. A devolução não é automática. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry] [BIP 65 — CHECKLOCKTIMEVERIFY]
update_add_htlc propõe a adição; update_fulfill_htlc ou update_fail_htlc tratam do cumprimento ou da falha. Uma mensagem isolada não conclui a mudança de estado: commitment_signed e revoke_and_ack asseguram as assinaturas do novo estado e a revogação do antigo de ambos os lados. Um pagamento comum não precisa de um novo registo num bloco, mas o financiamento e o encerramento do canal utilizam transações Bitcoin. [BOLT 2 — Channel state and HTLC handling]
A base da mensagem update_add_htlc é composta por channel_id, id, amount_msat, payment_hash, cltv_expiry e onion_routing_packet. amount_msat é expresso em millisatoshi. O nó verifica os limites do canal, a liquidez disponível e as condições de encaminhamento; o HTLC de saída tem parâmetros próprios. Não pode oferecer o HTLC seguinte antes de a adição do HTLC de entrada estar irrevogavelmente confirmada segundo o BOLT 2. [BOLT 2 — Channel state and HTLC handling]
O nó decifra a sua própria camada onion e verifica a sua integridade. Numa rota comum não ocultada, compara amt_to_forward e outgoing_cltv_value com o montante de entrada, a taxa e a diferença temporal exigida. O pacote não lhe fornece a rota completa. Isto não exclui, porém, a correlação de tráfego nem outras inferências de identidade; o encaminhamento onion não garante anonimato absoluto. [BOLT 4 — Onion routing and payload validation]
O HTLC de entrada tem de expirar mais tarde do que o HTLC de saída seguinte. A diferença cltv_expiry_delta dá ao intermediário uma margem para obter a preimage, reagir à indisponibilidade da contraparte e conseguir confirmação na cadeia. Inclui o risco de atrasos e reorganizações; um número de blocos não garante um número fixo de minutos. Uma margem demasiado pequena põe os fundos em risco. [BOLT 2 — Channel state and HTLC handling]
O BOLT 3 distingue saídas offered e received e caminhos HTLC-success ou HTLC-timeout. O simples conhecimento de um hash não basta: aplicam-se as assinaturas, a preimage e as condições temporais correspondentes. A saída local da segunda fase tem o atraso CSV to_self_delay, enquanto a chave de revogação correta permite à contraparte utilizar o ramo de penalização sem esse atraso. O Script exato depende do tipo de canal. [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
Se o montante, após a taxa aplicável da segunda fase, não atingir dust_limit_satoshis, a transação de commitment não cria uma saída HTLC. As regras dependem do tipo negociado: option_anchors e zero_fee_commitments não têm essa taxa da segunda fase; zero_fee_commitments pode encaminhar o valor excluído para shared_anchor. Uma saída inexistente não pode ser reclamada separadamente na cadeia. A soma destes HTLC constitui a dust exposure. [BOLT 3 — HTLC transaction scripts and trimming] [BOLT 2 — Channel state and HTLC handling]
O mesmo segredo liga as condições ao longo da rota, mas aceitar a oferta não garante, por si só, um pagamento concluído. A liquidez, o número de HTLC disponíveis, as taxas, as expirações e as regras de encaminhamento podem interromper o pagamento. O cumprimento ou a falha seguros exigem a ordem correta das alterações e uma resolução atempada. Revelar a preimage não é o mesmo que confirmar uma transação Bitcoin. [BOLT 2 — Channel state and HTLC handling] [BOLT 4 — Onion routing and payload validation]
Compare amount_msat, payment_hash e cltv_expiry de entrada e de saída; verifique a preimage com SHA-256. Acompanhe também commitment_signed, revoke_and_ack e o estado final, não apenas uma mensagem fulfill/fail. Na execução na cadeia, descodifique a transação de commitment real e verifique a existência da saída, o ramo utilizado e HTLC-success/HTLC-timeout. Verifique assinaturas, condições temporais e confirmações; a simples descodificação não prova validade. [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, Payment Channel, Timelock, Hash criptográfico, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. Também há referências a este verbete em Timelock, Payment Channel, Liquidez Lightning, Lightning Routing.