Nova falha na Lightning Network do Bitcoin causa interrupções
Em menos de um mês, a rede Bitcoin Lightning sofreu mais um colapso. Assim, o evento ocorreu entre os usuários que usavam o cliente LND (Lightning Network Daemon). Portanto, com a falha os usuários ficarem fora de sincronia, limitando a abertura ou fechamento de canais de pagamento.
No entanto, apesar do fracasso, a rede continuou a encaminhar pagamentos.
Anteriormente, em 10 de outubro, uma transação de quase 1.000 assinaturas fez com que a rede sofresse interrupções. Assim, como correção, o código sofreu alterações com um novo valor, especificamente maxWitnessItemPerInput (que coleta o número máximo de assinaturas) para 500.000.
No entanto, mesmo com a correção, a rede voltou da ‘dar problema’. Desse modo, em 01 de novembro, um usuário deliberadamente e como um teste de estresse criou uma transação que fingia ter 500.001 “assinaturas”. Portanto, como da outra vez, isso fez com que os clientes LND travassem.
Bitcoin
A criação de uma transação desse tamanho ocorreu graças ao Taproot, uma das atualizações mais recentes e importantes que o Bitcoin recebeu. Desse modo, com Taproot, há suporte para transações com um número maior de assinaturas.
O LND é o cliente de nó mais usado na rede Lightning. Mesmo os nós com maior capacidade e com o maior número de pagamentos roteados trabalham diariamente usando este cliente. Portanto, a falha foi bastante significativa dentro da rede.
O usuário que criou a transação, e que usou o handle brqgoo no GitHub, sugere que o valor maxWitnessItemPerInput seja alterado para 4.000.000. Portanto, com isso, ele acha que o problema pode não ocorrer novamente.
Seguindo a sugestão, a equipe de desenvolvimento do LND lançou uma nova versão do cliente (v 0.15.4) que resolve esse problema. Dessa forma é necessário que todos os nós que usam o LND sejam atualizados.
O desenvolvedor Rene Pickhardt informou que a equipe de desenvolvimento do LND estava ciente desse vetor de ataque. Assim, Pickhardt explicou que mudar o maxWitnessItemPerInput para 4.000.000 já havia sido sugerido pela equipe de desenvolvimento.
.
