A norma de faturas BOLT11 exige agora exactamente um hash de pagamento e um segredo de pagamento. A ausência ou repetição destes campos deve provocar a falha do pagamento. Os programadores da Lightning fizeram a alteração em 19 de outubro, depois de um ataque divulgado mostrar como parsers de faturas em conflito poderiam fazer com que levantamentos de Bitcoin concluídos parecessem não pagos. O relato do incidente não indicou uma data nem o valor das perdas.
Porque é importante
A vulnerabilidade tinha origem na forma como componentes de software liam de maneira diferente o mesmo pedido de pagamento assinado. Um parser podia seleccionar o primeiro campo de hash de pagamento, enquanto outro seleccionava o último. Um serviço poderia, assim, registar um levantamento com um hash enquanto o seu nó executava o pagamento com outro, levando o sistema de contabilidade a tratar um levantamento concluído como não pago e, potencialmente, a emitir outro pagamento.
A nova regra abrange tanto os hashes de pagamento como os segredos de pagamento. As implementações têm de contar as ocorrências dos campos, incluindo valores idênticos repetidos, em vez de os agruparem numa única entrada. Uma fatura com dois hashes distintos e uma fatura que repita o mesmo hash são ambas inválidas ao abrigo da especificação actual.
Impacto no mercado
O impacto imediato é operacional, e não um sinal directo sobre o preço do Bitcoin. Os operadores de pagamentos têm de rejeitar faturas ambíguas e garantir que a contabilidade dos levantamentos segue o mesmo hash de pagamento utilizado pelo nó. A alteração também evidencia um risco mais amplo na infraestrutura cripto: dados assinados podem continuar a causar falhas quando software diferente interpreta os seus campos de forma inconsistente.
O software de nós lnd integrou a rejeição de hashes duplicados em 23 de setembro. As versões v0.20.5-beta e v0.21.4-beta incluem essa correcção. Uma proposta separada sobre a validação de segredos de pagamento e outras verificações do descodificador continuava em aberto em 27 de outubro, e uma descodificação bem-sucedida, por si só, não garante que um pagamento seja concluído.
Perguntas frequentes
-
O que mudou na norma de faturas BOLT11?
A BOLT11 exige agora exactamente um hash de pagamento e um segredo de pagamento. Campos ausentes ou repetidos devem fazer com que a fatura seja rejeitada.
-
Como poderiam parsers em conflito fazer um levantamento de Bitcoin parecer não pago?
Um parser podia usar o primeiro hash de pagamento, enquanto outro usava o último. Um serviço poderia então registar um hash diferente daquele usado pelo seu nó para executar o pagamento.
-
Que tipo de ataque levou à alteração das regras da BOLT11?
Um ataque divulgado contra um bot peer-to-peer do Telegram explorou diferenças entre bibliotecas de faturas, fazendo com que levantamentos de Bitcoin concluídos parecessem não pagos e abrindo caminho para pagamentos adicionais.
-
Que versões do lnd incluem a rejeição de hashes duplicados?
A correcção para hashes duplicados foi integrada em 23 de setembro e está incluída nas versões lnd v0.20.5-beta e v0.21.4-beta.
-
As verificações de segredos de pagamento já estão concluídas no lnd?
Não. Uma proposta separada do lnd sobre a validação de segredos de pagamento e outras verificações do descodificador continuava em aberto em 27 de outubro.
CoinDesk
CZ Binance
TheBlock