Segredo de pagamento

O segredo de pagamento da Lightning funciona como uma senha por fatura que o pagador devolve antes que o nó receptor aceite o dinheiro. O BOLT 11 dá a ele a letra de etiqueta s, fixa seu comprimento em 52 caracteres bech32 e orienta o leitor a rejeitar qualquer fatura que chegue sem um. Para você, é a razão pela qual um nó de roteamento que viu seu hash de pagamento não consegue saber que o pagamento terminou na sua carteira.

Como funciona

Um segredo de pagamento é criado pela carteira receptora, nunca pelo pagador, e permanece selado dentro da cebola até que o pagamento chegue ao seu último salto.

O BOLT 11 o define como campo etiquetado do tipo 16, escrito com a letra s e um data_length fixo de 52. Esses 52 caracteres bech32 carregam 260 bits, um valor de 32 bytes mais preenchimento, e quem escreve uma fatura deve incluir exatamente um. O leitor deve rejeitar o pagamento se um campo de comprimento fixo tiver o comprimento errado, e também se não houver nenhum campo s válido.

O pagador copia o valor para a carga útil da cebola do último nó, que o BOLT 4 chama de registro TLV do tipo 8, payment_data, contendo o segredo de 32 bytes e um valor total_msat. Somente o destino pode descascar essa camada, então os saltos intermediários nunca o veem, ao contrário do hash de pagamento ao qual todos prendem seus HTLCs.

A verificação na ponta final é deliberadamente pouco informativa. Um segredo que não corresponde ao esperado para aquele hash de pagamento, ou que é obrigatório e está ausente, faz o HTLC falhar com incorrect_or_unknown_payment_details, erro PERM|15, a mesma resposta que um hash de pagamento desconhecido recebe. O BOLT 4 explica a fusão: o par mais antigo, PERM|16 incorrect_payment_amount e 17 final_expiry_too_soon, permitia que um nó de encaminhamento reenviasse pagamentos com o mesmo hash por valores muito menores e lesse a resposta para confirmar que havia encontrado o destino.

O suporte não é mais negociado. O BOLT 9 lista os bits de recurso 14 e 15, payment_secret, como ASSUMED, e os bits 16 e 17, basic_mpp, dependem dele.

Onde você o vê

Você pode identificar um segredo de pagamento em uma string lnbc moderna como o trecho que começa com sp5 e continua por 52 caracteres de bech32.

Nos vetores de teste do BOLT 11, esse trecho é zyg3 repetido doze vezes e depois zygs, codificando um segredo cujos 32 bytes são todos 0x11. Você nunca digita um segredo de pagamento: somente quem escreve a fatura e a carteira pagadora alguma vez lidam com o valor.

Onde o campo se justifica é nos pagamentos multipartes. Quando nenhuma rota isolada tem liquidez suficiente e a fatura oferece basic_mpp, o BOLT 4 permite que uma carteira divida o valor entre vários HTLCs que compartilham um hash de pagamento, e cada parte deve carregar o segredo e deveria concordar com o total_msat. O receptor não liquida nada até que o total chegue, e deveria esperar pelo menos 60 segundos após o primeiro HTLC antes de rejeitar o conjunto com um mpp_timeout. Assim, um saque Lightning maior, que fica pendente por um minuto e depois retorna, vindo de um aplicativo que prioriza a Lightning, como o Strike, pode ser um conjunto de HTLC incompleto expirando, e não dinheiro perdido. Se é a sua própria carteira que monta essas partes, como a Phoenix faz ao executar um nó Lightning real no celular, ou se uma plataforma que guarda seus fundos faz isso em um servidor que você não controla, o segredo as marca como um único pagamento.

Segredo de pagamento vs hash de pagamento

O hash de pagamento e o segredo de pagamento são ambos campos de 256 bits em uma fatura BOLT 11, e a diferença está em quem pode vê-los. Cada salto conhece o hash, porque cada um prende a ele o HTLC que encaminha, enquanto ninguém além do nó final conhece o segredo, que viaja na camada mais interna da cebola. O hash responde se o pagamento foi liquidado, e a preimagem que o abre é o recibo. O segredo responde se o pagador está trabalhando a partir da fatura que você escreveu, o que um hash não pode fazer, por ser visível a todos na rota. Na codificação eles parecem gêmeos: etiqueta p e etiqueta s, ambas com 52 caracteres, ambas rejeitadas em qualquer outro comprimento.