Este endereço de Bitcoin ficou famoso: bc1qqhx2nydhdw5qhruslhwf74hdjq88lh662m8xy2 — um erro causou uma perda de 1,6 BTC. Não foi “destruído por acidente”; em vez disso, ele mandou o dinheiro para os mineradores da
@SpiderPool_com
. Agora que a indústria de mineração de Bitcoin está no inverno, isso é, sem dúvida, “um cobertor aquecendo no meio da neve”. As chances de recuperar os fundos explicando o erro para a SpiderPool são quase nulas, já que virou renda legítima dos mineradores. Ou então o dono da carteira não faz muita diferença: 1,6 BTC são só moedas de teste.
Vamos ver como ele operou. Segundo reportagem do site Beincrypto:
Um usuário de Bitcoin pagou 1,6 BTC (cerca de US$ 102.778) de taxa de rede em uma transação devido a um erro de software.
Na prática, não houve transferência: esta transação foi confirmada em 12 de agosto de 2026 no bloco 962.142 do Bitcoin. Os registros na cadeia mostram que os mais de 160 milhões de satoshis (satoshis) que entraram nesta transação foram integralmente recebidos pelos mineradores; ao destinatário final chegou o valor de 0 BTC.
Mineradores ganham sem querer: o pool de mineração SpiderPool minerou o bloco e empacotou essa transação. A taxa total desse bloco era de cerca de 1,82 BTC, e 88% vieram desse “deslize”.
Causa do incidente
O usuário executou um script automatizado que usava Replace-by-Fee (RBF, substituição por taxa), com o objetivo de acelerar transações não confirmadas ao aumentar a taxa.
Mas o script automatizado entrou em um ciclo lógico sem saída: a cada segundo, aumentava cegamente o lance, até consumir todo o saldo da carteira como gasto de taxas.
O protocolo da rede Bitcoin, por si só, não define um limite máximo de taxa para uma única transação; por isso, os nós continuaram recebendo e confirmando essa transação.
Recomendações de prevenção da Beincrypto
Para evitar que ferramentas automatizadas esvaziem a carteira, o artigo traz três dicas de segurança:
Desativar a atualização automática via RBF: usar confirmação manual, com auditoria humana antes de cada aceleração.
Definir um limite rígido de taxa: configurar, na carteira, um limite máximo de “saturação” (Sat/Byte) para transações individuais; ao exceder, encerrar imediatamente o script.
Testes com valores pequenos: antes de automatizar ou fazer transferências em lote, testar a lógica do script com uma quantia pequena (por exemplo, alguns milhares de satoshis).
@SpiderPool_com
. Agora que a indústria de mineração de Bitcoin está no inverno, isso é, sem dúvida, “um cobertor aquecendo no meio da neve”. As chances de recuperar os fundos explicando o erro para a SpiderPool são quase nulas, já que virou renda legítima dos mineradores. Ou então o dono da carteira não faz muita diferença: 1,6 BTC são só moedas de teste.
Vamos ver como ele operou. Segundo reportagem do site Beincrypto:
Um usuário de Bitcoin pagou 1,6 BTC (cerca de US$ 102.778) de taxa de rede em uma transação devido a um erro de software.
Na prática, não houve transferência: esta transação foi confirmada em 12 de agosto de 2026 no bloco 962.142 do Bitcoin. Os registros na cadeia mostram que os mais de 160 milhões de satoshis (satoshis) que entraram nesta transação foram integralmente recebidos pelos mineradores; ao destinatário final chegou o valor de 0 BTC.
Mineradores ganham sem querer: o pool de mineração SpiderPool minerou o bloco e empacotou essa transação. A taxa total desse bloco era de cerca de 1,82 BTC, e 88% vieram desse “deslize”.
Causa do incidente
O usuário executou um script automatizado que usava Replace-by-Fee (RBF, substituição por taxa), com o objetivo de acelerar transações não confirmadas ao aumentar a taxa.
Mas o script automatizado entrou em um ciclo lógico sem saída: a cada segundo, aumentava cegamente o lance, até consumir todo o saldo da carteira como gasto de taxas.
O protocolo da rede Bitcoin, por si só, não define um limite máximo de taxa para uma única transação; por isso, os nós continuaram recebendo e confirmando essa transação.
Recomendações de prevenção da Beincrypto
Para evitar que ferramentas automatizadas esvaziem a carteira, o artigo traz três dicas de segurança:
Desativar a atualização automática via RBF: usar confirmação manual, com auditoria humana antes de cada aceleração.
Definir um limite rígido de taxa: configurar, na carteira, um limite máximo de “saturação” (Sat/Byte) para transações individuais; ao exceder, encerrar imediatamente o script.
Testes com valores pequenos: antes de automatizar ou fazer transferências em lote, testar a lógica do script com uma quantia pequena (por exemplo, alguns milhares de satoshis).