HTLC

Anna quer enviar 20 000 sat a Pavel pela Lightning Network. Sat é a abreviatura de satoshi, a menor unidade de bitcoin na cadeia. Não partilham um canal de pagamento, mas ambos têm uma ligação adequada através de Eva. Um canal é um acordo entre dois participantes sobre a distribuição de bitcoins, atualizável sem registar cada pagamento num bloco. Eva oferece a Pavel 20 000 sat condicionados e Anna oferece 20 010 sat a Eva. A diferença de 10 sat é a taxa de Eva neste exemplo simplificado. São alterações de saldos ligadas em dois canais, não a passagem da mesma moeda individual por ambos. Pavel conhece um segredo que permite cumprir a sua condição. Eva pode depois usar o mesmo valor perante Anna. Não precisa de pagar primeiro a Pavel de forma irreversível com base apenas na promessa dele. As quantias ilustram o mecanismo, não uma taxa habitual ou recomendada. [1]

Pavel prepara para o pagamento um segredo aleatório de 32 bytes, a payment_preimage. SHA-256 calcula o respetivo payment_hash. É fácil verificar se um valor revelado produz a impressão digital certa; recuperar um segredo bem escolhido apenas a partir dela é praticamente inviável. Uma fatura BOLT 11 comum, um pedido de pagamento Lightning, contém o hash no campo p, não a preimage. Quando Pavel cumpre o pagamento, o segredo regressa pela rota e liga os HTLC correspondentes. O payment_secret do campo s é diferente: ajuda o destinatário a processar corretamente o pagamento e não substitui a preimage. Nenhum destes valores é uma Seed Phrase (as palavras para recuperar a carteira) ou a chave privada da carteira. [1] [4]

Se ambos os pagamentos tivessem o mesmo prazo, Pavel poderia revelar o segredo demasiado tarde para Eva reclamar o pagamento de entrada. Por isso, o HTLC vindo de Anna expira depois do HTLC que Eva oferece a Pavel. A diferença, cltv_expiry_delta, dá uma margem a Eva. Também precisa dela se a contraparte deixar de responder e for necessário executar o acordo com transações Bitcoin na cadeia. A margem mede-se em blocos, não em minutos exatos, e deve contar com atrasos e reorganizações. A configuração segura depende do software e das regras do canal; uma margem insuficiente põe os fundos em risco. Numa reorganização, parte da cadeia é substituída por outro ramo válido, o que pode alterar confirmações anteriores de transações. [1]

No Lightning, cltv_expiry é uma altura de bloco, a sua posição na cadeia. Não é um timestamp Unix (uma data e hora expressas em número de segundos) nem a validade em segundos de uma fatura BOLT 11. Cumpridas as condições temporais, pode ficar disponível a via timeout, para liquidar sem o segredo. Os fundos não se movem sozinhos: os nós Lightning, os programas que gerem os canais de pagamento, têm de concluir corretamente a alteração do canal ou utilizar a transação correspondente na cadeia. Uma preimage válida também não deixa de funcionar automaticamente no fim do prazo. Se a mesma saída, uma quantia com regras de gasto, ainda não tiver sido gasta de outra forma, vias permitidas podem competir; os dois gastos não podem ser confirmados numa mesma cadeia válida. Agir a tempo faz, por isso, parte da segurança. [1] [4] [5]

Um HTLC liga condições, mas não faz qualquer quantia passar por qualquer rota. Eva precisa de fundos suficientes no sentido de saída, ou seja, liquidez, e de espaço para mais um HTLC pendente. Limites, taxas ou um nó indisponível podem travar o pagamento. Enquanto a tentativa pendente não for devidamente resolvida, parte dos fundos pode continuar comprometida com ela. O estado da carteira descreve a tentativa inteira; uma mensagem isolada não comprova o resultado. Revelar a preimage não equivale a confirmar uma transação Bitcoin. Um pagamento Lightning comum bem-sucedido liquida-se por atualizações dos canais, sem registar cada pagamento num novo bloco. [1] [3]

As secções seguintes são uma referência técnica. O estado do canal indica a quem pertence cada quantia e quais os HTLC ainda pendentes. Uma commitment transaction é uma transação Bitcoin assinada que permite executar esse estado na cadeia. update_add_htlc apenas propõe uma adição; update_fulfill_htlc comunica o cumprimento e update_fail_htlc a falha. Anunciar a alteração não basta. Com commitment_signed e revoke_and_ack, as partes trocam assinaturas do novo estado e dados que tornam insegura a utilização do antigo. Segundo o BOLT 2, ambas têm de assumir irrevogavelmente a alteração pertinente antes de outro compromisso depender dela. Este acordo entre participantes não é uma confirmação num bloco. O financiamento e o eventual encerramento do canal, por sua vez, dependem de transações Bitcoin. [1]

Os campos são dados individuais de uma mensagem. Um millisatoshi é um milésimo de satoshi, uma unidade contabilística interna ao Lightning; não é uma fração que se possa gastar separadamente na cadeia Bitcoin. 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. [1]

Onion routing envolve as instruções de cada intermediário em camadas cifradas separadas. Eva recebe o necessário para o seu passo, não uma lista legível de todos os participantes. 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. [3]

Uma saída é uma quantia com regras de gasto escritas na linguagem Script. Offered e received designam HTLC oferecidos e recebidos do ponto de vista do participante. A segunda fase é uma transação seguinte; CHECKSEQUENCEVERIFY (CSV) impõe uma espera a partir da confirmação da saída que se gasta. Uma chave de revogação permite penalizar a publicação de um estado antigo já revogado. 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. [2] [6]

Trimming significa que um HTLC pequeno não se transforma numa saída separada ao levar o estado do canal para a cadeia. Dust designa essas pequenas quantias. Dust exposure mede o valor total sujeito a essa limitação. 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. [2] [1]

A verificação seguinte destina-se a operadores de nós e programadores. Descodificar apresenta um registo como campos legíveis; não envia nada nem comprova, por si só, que todas as condições estão cumpridas. 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. [1] [2]