O Eclair integrou duas correções para evitar que nós da Lightning Network paguem taxas de mineração excessivas ao financiar canais ou realizar operações de splicing. As alterações entraram no ramo principal do projeto a 2 e 5 de outubro. No entanto, a 12 de outubro, a página de versões continuava a indicar a v0.14.3, lançada em setembro, como a mais recente; não está confirmado, portanto, que as correções já façam parte de uma versão publicada.
Desenvolvido pela ACINQ, o Eclair é um software para operar nós Lightning. As correções abrangem as taxas em canais financiados por ambas as partes e em operações de splicing, além da validação de transações no modo Eclair-signer. Caso haja perdas, estas correspondem a taxas pagas aos mineradores, e não a uma transferência direta para um atacante.
PR #3388 limita aumentos de taxa propostos pela contraparte
A primeira correção, PR #3388, trata de transações de substituição por taxa (RBF, na sigla em inglês) iniciadas pela contraparte. Ao abrir um canal com financiamento partilhado ou alterar o financiamento de um canal através de splicing, a contraparte pode propor uma transação de substituição com uma taxa mais elevada. Antes da correção, um nó Eclair que contribuísse com fundos podia acabar por pagar mais pela sua parte da transação, sem que o processo definisse um limite explícito para a taxa ou para o orçamento.
Assim, uma contraparte mal-intencionada poderia levar o nó financiador a aceitar uma taxa de mineração arbitrariamente elevada, sem suportar o custo adicional. A perda para o nó seria paga aos mineradores como taxa da transação, e não diretamente à contraparte.
Com a alteração, o Eclair rejeita pedidos que ultrapassem o limite de taxa recomendado para a transação de financiamento. A restrição não se aplica quando a contraparte paga pela liquidez e cobre a taxa de contribuição do Eclair, nem quando o nó Eclair não contribui para a transação. Nesses casos, o nó não suporta o custo que a correção pretende limitar.
PR #3390 verifica as taxas reais no modo signer
A segunda correção, PR #3390, diz respeito ao modo Eclair-signer. Nesta configuração, o backend Bitcoin Core, o bitcoind, seleciona os bitcoins e constrói a transação, enquanto o Eclair mantém as chaves privadas e a assina. O facto de as chaves de assinatura permanecerem no Eclair não basta para proteger o nó se o backend estiver comprometido: este pode indicar uma taxa dentro do orçamento, mas construir uma transação que paga mais, por exemplo, removendo um output de troco para aumentar a taxa de mineração.
Numa transação Bitcoin, o valor dos inputs que não é atribuído a outputs transforma-se na taxa paga aos mineradores. A remoção do troco pode, por isso, custar dinheiro ao nó sem enviar os fundos para um endereço controlado por um atacante.
A correção calcula a taxa efetiva a partir do valor dos inputs utilizados e consulta as transações relevantes pelo respetivo ID para verificar esses montantes. Em seguida, o Eclair compara a taxa comunicada pelo backend com o valor calculado e aplica o limite orçamental à taxa efetiva, em vez de confiar apenas nos dados fornecidos pelo backend. A correção também verifica se a parte de financiamento reconstruída pelo Eclair paga a mesma taxa validada e rejeita transações com uma posição inválida para o output de troco.
Alterações de outubro ainda não constam de uma versão publicada
As duas alterações introduzem limites às taxas em operações de financiamento partilhado e splicing, além de verificações das taxas de transação no modo signer. São distintas de uma vulnerabilidade anterior relacionada com as taxas de fecho cooperativo de canais e do problema de negação de serviço divulgado a 2 de outubro, que poderia afetar nós após um reinício.
A 12 de outubro, a página de versões do Eclair ainda apresentava a v0.14.3, lançada em setembro, como a mais recente. A integração de alterações no ramo principal não confirma que estejam disponíveis numa versão distribuída. Os operadores de nós terão de verificar se a versão instalada já inclui as alterações de outubro.