Hash de pagamento

Cada salto de uma rota Lightning vê o mesmo hash de pagamento, que é o que identifica o pagamento para cada um deles. O BOLT 11 exige exatamente um por fatura, escrito como 52 caracteres bech32 que carregam 256 bits. Mostrar o segredo correspondente é a única forma de resgatar o dinheiro, e guardar esse segredo depois é o seu recibo.

Como funciona

Um hash de pagamento começa a vida como o seu oposto: o destinatário escolhe 32 bytes aleatórios, chamados de preimagem do pagamento, e publica apenas o SHA-256 deles.

Esse valor entra na fatura sob a etiqueta p, que o BOLT 11 fixa em um data_length de 52 e exige exatamente uma vez. A partir daí, ele percorre a rota dentro de update_add_htlc, mensagem do tipo 128, cujos campos são o id do canal, um contador de 64 bits, o valor em milisatoshis, o próprio payment_hash, uma expiração CLTV e uma cebola de 1366 bytes. Ele cumpre uma dupla função nessa mensagem: também é fornecido à construção da cebola como dados associados, de modo que os HMACs de cada salto se comprometem com ele. Repetir um pacote de cebola antigo contra um hash de pagamento diferente, portanto, falha no primeiro nó que faz a verificação.

A liquidação percorre o hash no sentido inverso. O destinatário devolve a preimagem em update_fulfill_htlc, mensagem do tipo 130, como um valor simples de 32 bytes, e cada nó anterior a repassa pelos mesmos canais. Um nó que recebe uma preimagem cujo SHA-256 não corresponde ao hash que ele mantém não a ignora simplesmente: o BOLT 2 diz que ele deve enviar um aviso e fechar a conexão, ou enviar um erro e fazer o canal falhar, porque não há explicação inocente.

On-chain, o hash é cortado. O script de saída do HTLC não contém o valor de 32 bytes; ele executa uma comparação OP_HASH160 com RIPEMD160(payment_hash), um compromisso de 20 bytes, e quem gasta fornece a preimagem na testemunha. Dois HTLCs oferecidos com o mesmo valor arredondado e o mesmo hash de pagamento produzem saídas idênticas byte a byte mesmo quando suas expirações diferem, e é por isso que o BOLT 3 precisa especificar uma regra de ordenação para eles.

Um requisito parece estranho até você ver o ataque por trás dele. Um nó deve aceitar vários HTLCs que carregam o mesmo hash de pagamento, e o BOLT 2 dá o motivo: se as duplicatas fossem recusadas, um atacante poderia sondar com um hash conhecido e descobrir se aquele nó já mantinha aquele pagamento. O id separado de 64 bits existe para distinguir as duplicatas.

Por que isso importa quando você compra bitcoin

Duas das 63 corretoras analisadas neste site documentam um pagamento por Lightning em suas notas de taxas: a Strike, cuja nota de saque diz que saques para carteiras são aceitos por Lightning e on-chain, e a Coinbase, cuja tabela de taxas precifica um envio por Lightning em 0,2% do valor enviado.

Quando um desses pagamentos trava, não há id de transação para consultar, porque nada chegou à blockchain. O hash de pagamento é a única sequência que tanto o registro da sua carteira quanto o setor de retaguarda da corretora possuem, então copie-o da tela de detalhes do pagamento antes de fechá-la. Um suporte que pede “o id da transação” de um saque por Lightning está pedindo esse valor.

O erro que você recebe não dirá muita coisa, e isso é proposital. O BOLT 4 reúne cinco problemas distintos em um único código de falha, incorrect_or_unknown_payment_details, numerado PERM|15: o nó final não conhece o hash, o segredo de pagamento não corresponde a ele, o valor para esse hash é baixo demais, a expiração está perto demais da altura de bloco atual ou faltam metadados de pagamento obrigatórios. A especificação explica a fusão. Os códigos separados mais antigos permitiam que um nó de encaminhamento adivinhasse para onde ia um pagamento, enviando o mesmo hash adiante com um valor muito menor e lendo a resposta. Sua carteira não está escondendo o motivo de você, ela nunca foi informada, então gerar a fatura de novo e pagar outra vez é a resposta prática.

O mesmo valor permanece idêntico do seu nó ao do destinatário, inclusive em todas as partes de um pagamento multipartes, que o BOLT 4 exige que compartilhem um único hash de pagamento. Quem o vê duas vezes sabe que está diante de um único pagamento. Nossa análise da Phoenix cita o próprio FAQ da ACINQ, que admite conhecer o destino final e o valor dos pagamentos feitos pela carteira, o que é a versão direta da mesma exposição, declarada pelo fornecedor e não inferida por este site.

Reutilizar uma fatura é pior do que inútil por um motivo relacionado. O BOLT 4 deixa um nó final que recebe um hash já pago livre para tratá-lo como desconhecido ou para aceitar o dinheiro, então o resultado de um código QR publicado de novo depende da implementação que o destinatário por acaso executa.

Decodificar o hash de pagamento no vetor de teste de doação do BOLT 11

A especificação BOLT 11 inclui uma fatura de doação resolvida, e o hash de pagamento dentro dela é um valor de teste fixo que nenhuma carteira deveria jamais produzir.

O exemplo tem como título "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102" e a sequência começa com lnbc1pvjluez. Depois do prefixo lnbc e do separador bech32, pvjluez é o carimbo de data e hora, 1496314658 segundos desde o início de 1970. O campo do segredo de pagamento vem em seguida, e depois dele a etiqueta p, e então p5, que é o comprimento: em bech32, p é 1 e 5 é 20, então o campo ocupa 1 * 32 + 20 = 52 caracteres. Esses caracteres, qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, decodificam para o hash citado naquele título.

Nada nisso é privado. A especificação publica a chave privada com que seus exemplos são assinados, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, e diz que toda fatura daquela seção carrega o segredo de pagamento 1111111111111111111111111111111111111111111111111111111111111111, a menos que indique o contrário, então essas sequências são dados de teste para analisadores, e não pedidos de pagamento. Se uma carteira ou uma ferramenta de diagnóstico algum dia mostrar esse hash fora de um conjunto de testes, algo está repetindo a especificação em vez de informar o seu pagamento.

Hash de pagamento vs id de transação

Um hash de pagamento nomeia um pagamento Lightning; um id de transação nomeia uma transação que existe na blockchain do bitcoin. Ambos têm 32 bytes e ambos são impressos como 64 caracteres hexadecimais, e é assim que cada um acaba nos formulários de suporte do outro. Um id de transação é calculado a partir dos próprios bytes da transação depois que ela existe e pode ser colado em qualquer explorador de blocos. Um hash de pagamento é escolhido pelo destinatário antes de o pagamento existir, nunca aparece em um bloco quando o pagamento é liquidado normalmente e não retorna nada em um explorador. Um resultado de busca vazio geralmente significa que você tem o valor certo e a ferramenta errada.

Hash de pagamento vs segredo de pagamento

Um hash de pagamento e um segredo de pagamento são dois valores diferentes de 256 bits na mesma fatura, carregados nas etiquetas p e s e cada um codificado como 52 caracteres bech32. O hash é necessariamente público: cada salto precisa vê-lo para construir seu HTLC. O segredo é entregue apenas ao último nó, dentro da cebola, e o BOLT 11 declara sua função em uma linha, que ele "prevents forwarding nodes from probing the payment recipient". Um leitor que não encontra nenhum campo s deve fazer o pagamento falhar de imediato. O hash é a fechadura; o segredo é a prova de que quem está pagando obteve a fatura da pessoa que a emitiu.