A Blockstream, desta vez, não perdeu nenhuma chave privada — a assinatura federada correu do início ao fim exatamente como foi planejado. Os nós funcionais fizeram as validações necessárias e, então, conforme as regras, colocaram os bitcoins em circulação. O problema é que aquele lote de L-BTC exigindo resgate foi criado do nada, e ninguém percebeu.
O incidente aconteceu em 6 de setembro. Alguém explorou uma falha no Elements para “fabricar” no Liquid cerca de 4.000 unidades de L-BTC sem lastro em bitcoin. Esses títulos foram então entregues ao membro do federado SideSwap e passaram por todo o fluxo de peg-out de forma totalmente normal. Em pouco mais de meia hora, quase 4.000 L-BTC $BTC saíram do endereço de reserva do federado; convertidos pela cotação da época, isso ultrapassou 300 milhões de dólares.
Antes do ocorrido, havia 4.205 unidades nesse endereço. Somando aquele peg-out e algumas etapas posteriores, só restaram 197 unidades. A cadeia foi então interrompida e, até agora, não foi reaberta.
A falha estava na camada de confidencialidade de transações. No Liquid, o valor das transferências é ocultado; os nós confirmam que o “balanço” de uma transação está correto usando range proofs. Ver esse tipo de prova queima bastante poder computacional, então o Elements passou a armazenar em cache os resultados já verificados para reutilizá-los.
A chave do cache ignorava o contexto de “asset” (ativo) e “script”. Assim, uma prova já verificada em outro lugar podia ser reaproveitada para dar lastro a uma emissão totalmente nova. No Elements 23.3.4, a oficial corrigiu essa correção: reforçar a chave de cache dos range proofs e, adicionalmente, adicionar uma opção para que os nós simplesmente não cacheassem.
O problema não era com o esquema de limiar em si. Em quinze chaves, juntar onze para assinar é a regra; e as pessoas que assinaram eram de fato as corretas. O que os nós funcionais verificaram foi se aquele peg-out foi iniciado por um membro com permissão de PAK; quanto a saber se, na origem, aqueles L-BTC tinham realmente entrado com bitcoins, não estava no escopo dessa verificação. Os nós do SideSwap e os nós funcionais globais executaram a mesma versão do Elements, caíram na mesma falha de cache e receberam a mesma resposta — não dá para dizer que cada um validou de forma independente. Mesmo elevando o limiar, o resultado seria idêntico.
A tipificação dessas pessoas ainda não ficou acordada fora. Do outro lado, na mainchain, alguém deixou uma mensagem se apresentando como “white hat” e pedindo para contatar a corrente; a Blockstream respondeu com um e-mail de segurança. Na noite de 7 de setembro, 3.400 bitcoins voltaram ao endereço de reserva; as 598,5 unidades restantes não se mexeram até hoje. Na época, o CTO da Ledger, Charles Guillemet, disse que um white hat não vai primeiro “esvaziar uma ponte” e depois vir pedir seus dados de contato. Mais tarde ele suavizou um pouco: admitiu que isso realmente não parece a conduta típica de um white hat, mas organizações criminosas comuns também não costumam contatar ativamente as vítimas. Ao deixar aquele dinheiro, ele preferiria chamar de extorsão. Já Samson Mow, da JAN3, mencionou que o pedido para transferir para o Signal veio de outro endereço.
Eu não aceito o termo “white hat”. Quem leva dinheiro para barganhar não é white hat. Mas isso é uma coisa diferente de saber se o dinheiro pode ser recuperado; neste momento a Blockstream não tem uma alavanca melhor.
O elo em que deu problema foi a validação das contas. A camada de custódia, na prática, não quebrou — e isso merece ser lembrado. No roadmap de maio da Blockstream havia uma ponte do tipo BitVM 1-of-n: a ideia era reduzir a confiança de um grupo para bastar ter uma pessoa honesta para tudo funcionar. Aquele desenho lida com conluio e fuga, mas não consegue cobrir todos os cenários em que todo mundo execute o mesmo código e veja o mesmo lugar com a mesma interpretação errada. Mesmo que dentro do federado haja cem membros honestos, eles ainda leem o mesmo livro contábil contaminado.
Por isso, para as pessoas que detêm BTC em diferentes “embalagens” ou fazem BTC cross-chain, o número de signatários não é um indicador tão relevante. Vou perguntar três coisas: quem tem autorização para cunhar novos títulos; depois de cunhados, o que se usa para validar; e se as partes que validam calcularam cada uma de forma independente. A terceira é o ponto-chave desta vez. O próprio #Bitcoin da mainchain está completamente ok; o problema sempre foi nesta camada ao lado.
O modelo federado também tem seus benefícios desta vez, é preciso reconhecer. Se a cadeia for interrompida, as contas ruins param ali; se você troca por outra cadeia que ninguém consegue parar e encontra uma falha de inflação, títulos sem lastro se espalham por todos os downstream — e não dá para recolher de volta.
O patch foi enviado antes do amanhecer de 9 de setembro, mas a cadeia permaneceu parada na mesma etapa de 7 de setembro. Do lado do código, já estava pronto; o que travava era apagar do livro aquela emissão peg-out inválida e, além disso, decidir quem cobriria o déficit. O endereço de reserva agora está com 3.601 bitcoins; lá fora, aguardando liquidação, ainda há mais de 4.100 L-BTC. A versão oficial disse que, ao reiniciar, aquela saída inválida seria recusada e o lastro suficiente seria restaurado, mas não disse quem preencheria esse buraco. Se no fim o buraco for coberto pela própria Blockstream ou pelos membros do federado com recursos próprios, então isso seria um acidente de código — e a crítica direcionada à custódia não chegaria a lugar nenhum. Se o buraco cair sobre os detentores de L-BTC, aí a crítica ganharia evidência.
Vale observar o saldo daquele endereço de reserva. Assim que a cadeia voltar a produzir blocos, ver se o saldo foi recomposto é mais direto do que qualquer comunicado.
O incidente aconteceu em 6 de setembro. Alguém explorou uma falha no Elements para “fabricar” no Liquid cerca de 4.000 unidades de L-BTC sem lastro em bitcoin. Esses títulos foram então entregues ao membro do federado SideSwap e passaram por todo o fluxo de peg-out de forma totalmente normal. Em pouco mais de meia hora, quase 4.000 L-BTC $BTC saíram do endereço de reserva do federado; convertidos pela cotação da época, isso ultrapassou 300 milhões de dólares.
Antes do ocorrido, havia 4.205 unidades nesse endereço. Somando aquele peg-out e algumas etapas posteriores, só restaram 197 unidades. A cadeia foi então interrompida e, até agora, não foi reaberta.
A falha estava na camada de confidencialidade de transações. No Liquid, o valor das transferências é ocultado; os nós confirmam que o “balanço” de uma transação está correto usando range proofs. Ver esse tipo de prova queima bastante poder computacional, então o Elements passou a armazenar em cache os resultados já verificados para reutilizá-los.
A chave do cache ignorava o contexto de “asset” (ativo) e “script”. Assim, uma prova já verificada em outro lugar podia ser reaproveitada para dar lastro a uma emissão totalmente nova. No Elements 23.3.4, a oficial corrigiu essa correção: reforçar a chave de cache dos range proofs e, adicionalmente, adicionar uma opção para que os nós simplesmente não cacheassem.
O problema não era com o esquema de limiar em si. Em quinze chaves, juntar onze para assinar é a regra; e as pessoas que assinaram eram de fato as corretas. O que os nós funcionais verificaram foi se aquele peg-out foi iniciado por um membro com permissão de PAK; quanto a saber se, na origem, aqueles L-BTC tinham realmente entrado com bitcoins, não estava no escopo dessa verificação. Os nós do SideSwap e os nós funcionais globais executaram a mesma versão do Elements, caíram na mesma falha de cache e receberam a mesma resposta — não dá para dizer que cada um validou de forma independente. Mesmo elevando o limiar, o resultado seria idêntico.
A tipificação dessas pessoas ainda não ficou acordada fora. Do outro lado, na mainchain, alguém deixou uma mensagem se apresentando como “white hat” e pedindo para contatar a corrente; a Blockstream respondeu com um e-mail de segurança. Na noite de 7 de setembro, 3.400 bitcoins voltaram ao endereço de reserva; as 598,5 unidades restantes não se mexeram até hoje. Na época, o CTO da Ledger, Charles Guillemet, disse que um white hat não vai primeiro “esvaziar uma ponte” e depois vir pedir seus dados de contato. Mais tarde ele suavizou um pouco: admitiu que isso realmente não parece a conduta típica de um white hat, mas organizações criminosas comuns também não costumam contatar ativamente as vítimas. Ao deixar aquele dinheiro, ele preferiria chamar de extorsão. Já Samson Mow, da JAN3, mencionou que o pedido para transferir para o Signal veio de outro endereço.
Eu não aceito o termo “white hat”. Quem leva dinheiro para barganhar não é white hat. Mas isso é uma coisa diferente de saber se o dinheiro pode ser recuperado; neste momento a Blockstream não tem uma alavanca melhor.
O elo em que deu problema foi a validação das contas. A camada de custódia, na prática, não quebrou — e isso merece ser lembrado. No roadmap de maio da Blockstream havia uma ponte do tipo BitVM 1-of-n: a ideia era reduzir a confiança de um grupo para bastar ter uma pessoa honesta para tudo funcionar. Aquele desenho lida com conluio e fuga, mas não consegue cobrir todos os cenários em que todo mundo execute o mesmo código e veja o mesmo lugar com a mesma interpretação errada. Mesmo que dentro do federado haja cem membros honestos, eles ainda leem o mesmo livro contábil contaminado.
Por isso, para as pessoas que detêm BTC em diferentes “embalagens” ou fazem BTC cross-chain, o número de signatários não é um indicador tão relevante. Vou perguntar três coisas: quem tem autorização para cunhar novos títulos; depois de cunhados, o que se usa para validar; e se as partes que validam calcularam cada uma de forma independente. A terceira é o ponto-chave desta vez. O próprio #Bitcoin da mainchain está completamente ok; o problema sempre foi nesta camada ao lado.
O modelo federado também tem seus benefícios desta vez, é preciso reconhecer. Se a cadeia for interrompida, as contas ruins param ali; se você troca por outra cadeia que ninguém consegue parar e encontra uma falha de inflação, títulos sem lastro se espalham por todos os downstream — e não dá para recolher de volta.
O patch foi enviado antes do amanhecer de 9 de setembro, mas a cadeia permaneceu parada na mesma etapa de 7 de setembro. Do lado do código, já estava pronto; o que travava era apagar do livro aquela emissão peg-out inválida e, além disso, decidir quem cobriria o déficit. O endereço de reserva agora está com 3.601 bitcoins; lá fora, aguardando liquidação, ainda há mais de 4.100 L-BTC. A versão oficial disse que, ao reiniciar, aquela saída inválida seria recusada e o lastro suficiente seria restaurado, mas não disse quem preencheria esse buraco. Se no fim o buraco for coberto pela própria Blockstream ou pelos membros do federado com recursos próprios, então isso seria um acidente de código — e a crítica direcionada à custódia não chegaria a lugar nenhum. Se o buraco cair sobre os detentores de L-BTC, aí a crítica ganharia evidência.
Vale observar o saldo daquele endereço de reserva. Assim que a cadeia voltar a produzir blocos, ver se o saldo foi recomposto é mais direto do que qualquer comunicado.