Bitcoin de transações duplicadas: uma falha interessante mas com risco reduzido
As transações de Bitcoin geralmente utilizam saídas não gastas referindo-se ao ID da transação anterior. Essas saídas só podem ser gastas uma vez, caso contrário, isso resultará em um pagamento duplo, fazendo com que o Bitcoin perca valor. No entanto, na história do Bitcoin, ocorreram de fato dois conjuntos de transações idênticas. Essa situação pode acontecer porque as transações coinbase não têm entradas, mas geram novos moedas diretamente. Portanto, duas transações coinbase diferentes podem enviar a mesma quantidade de moeda para o mesmo endereço, construídas de forma exatamente igual, resultando no mesmo ID de transação.
Estas duas séries de transações duplicadas ocorreram entre 14 e 15 de novembro de 2010, com um intervalo de tempo de aproximadamente 16 horas. A primeira série de transações duplicadas (d5d2....8599) está intercalada entre a segunda série (e3bf....b468). Curiosamente, d5d2....8599, embora tenha se tornado uma transação duplicada primeiro, apareceu na blockchain depois de e3bf....b468.
Estas transações repetidas têm um valor de 50 BTC cada, totalizando 200 BTC ou 100 BTC(, dependendo da forma como se entende). Até agora, estas moedas ainda não foram gastas. Teoricamente, quem possui a chave privada pode gastar estes Bitcoins, mas apenas 100 BTC podem realmente ser recuperados. Quanto a saber de qual bloco vêm estas moedas, pode não ser possível determinar.
Transações duplicadas podem causar confusão para carteiras e exploradores de blocos, e também podem ser usadas para ataques. Por exemplo, um atacante pode fazer dois pagamentos duplicados para uma exchange e, em seguida, retirar rapidamente os fundos, tentando levar a exchange à falência.
Para resolver este problema, em março de 2012 foi implementado o fork suave BIP30, que proíbe o uso de TXID duplicados para transações. Em setembro de 2012, esta regra foi ainda mais modificada, aplicando-se a todos os blocos (, exceto aos dois conjuntos de transações duplicadas mencionados anteriormente ). O BIP34, ativado em março de 2013, exige que as transações coinbase incluam a altura do bloco, o que parece resolver fundamentalmente o problema das transações duplicadas.
No entanto, alguns scripts de coinbase de transações antes da ativação do BIP34 têm o primeiro byte exatamente correspondente à altura do bloco que será válida no futuro. Isso significa que, em certas alturas de bloco específicas, ainda é possível criar transações duplicadas. O próximo bloco onde podem ocorrer transações duplicadas é 1,983,702, previsto para ser gerado por volta de janeiro de 2046.
Apesar disso, o custo e a dificuldade de explorar esta vulnerabilidade são muito altos. Os mineradores não só precisam ter sorte suficiente para minerar um bloco específico, como também precisam gastar uma grande quantidade de taxas. Com o preço atual do Bitcoin, esse ataque pode custar mais de 15 milhões de dólares, e praticamente não tem utilidade prática.
Considerando a dificuldade de copiar transações, os custos e a escassez de oportunidades, essa vulnerabilidade não representa uma ameaça de segurança significativa para o Bitcoin. No entanto, dado a escala de tempo envolvida e a singularidade das transações repetidas, essa questão ainda é instigante. Os desenvolvedores de Bitcoin investiram muito tempo nesta questão ao longo dos anos, e 2046 pode ser o prazo final para corrigir essa vulnerabilidade de forma abrangente. A solução pode exigir um soft fork, sendo uma das possíveis abordagens a imposição do compromisso SegWit.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
21 Curtidas
Recompensa
21
8
Repostar
Compartilhar
Comentário
0/400
PositionPhobia
· 07-08 21:33
2046, vamos falar disso depois, primeiro é preciso viver.
Ver originalResponder0
TestnetScholar
· 07-08 20:31
2046 é muito longe, hoje há vinho e hoje estou bêbado.
Ver originalResponder0
LayoffMiner
· 07-07 01:31
Ai, até 2046 nos vemos, a máquina funciona normalmente.
Ver originalResponder0
RektButSmiling
· 07-05 22:06
Vamos falar sobre isso em 2046. Estou fora, estou fora~
Ver originalResponder0
ruggedNotShrugged
· 07-05 22:05
Quem mais poderá viver até 2046 para ver a correção de falhas?
Ver originalResponder0
ser_we_are_ngmi
· 07-05 22:05
Ainda tens de esperar 23 anos. Por que tens tanta pressa...
Ver originalResponder0
MetaNomad
· 07-05 21:54
2046 parece ainda bastante longe, vou dormir um pouco.
Vulnerabilidade de transação duplicada do Bitcoin: a correção final pode chegar em 2046
Bitcoin de transações duplicadas: uma falha interessante mas com risco reduzido
As transações de Bitcoin geralmente utilizam saídas não gastas referindo-se ao ID da transação anterior. Essas saídas só podem ser gastas uma vez, caso contrário, isso resultará em um pagamento duplo, fazendo com que o Bitcoin perca valor. No entanto, na história do Bitcoin, ocorreram de fato dois conjuntos de transações idênticas. Essa situação pode acontecer porque as transações coinbase não têm entradas, mas geram novos moedas diretamente. Portanto, duas transações coinbase diferentes podem enviar a mesma quantidade de moeda para o mesmo endereço, construídas de forma exatamente igual, resultando no mesmo ID de transação.
Estas duas séries de transações duplicadas ocorreram entre 14 e 15 de novembro de 2010, com um intervalo de tempo de aproximadamente 16 horas. A primeira série de transações duplicadas (d5d2....8599) está intercalada entre a segunda série (e3bf....b468). Curiosamente, d5d2....8599, embora tenha se tornado uma transação duplicada primeiro, apareceu na blockchain depois de e3bf....b468.
Estas transações repetidas têm um valor de 50 BTC cada, totalizando 200 BTC ou 100 BTC(, dependendo da forma como se entende). Até agora, estas moedas ainda não foram gastas. Teoricamente, quem possui a chave privada pode gastar estes Bitcoins, mas apenas 100 BTC podem realmente ser recuperados. Quanto a saber de qual bloco vêm estas moedas, pode não ser possível determinar.
Transações duplicadas podem causar confusão para carteiras e exploradores de blocos, e também podem ser usadas para ataques. Por exemplo, um atacante pode fazer dois pagamentos duplicados para uma exchange e, em seguida, retirar rapidamente os fundos, tentando levar a exchange à falência.
Para resolver este problema, em março de 2012 foi implementado o fork suave BIP30, que proíbe o uso de TXID duplicados para transações. Em setembro de 2012, esta regra foi ainda mais modificada, aplicando-se a todos os blocos (, exceto aos dois conjuntos de transações duplicadas mencionados anteriormente ). O BIP34, ativado em março de 2013, exige que as transações coinbase incluam a altura do bloco, o que parece resolver fundamentalmente o problema das transações duplicadas.
No entanto, alguns scripts de coinbase de transações antes da ativação do BIP34 têm o primeiro byte exatamente correspondente à altura do bloco que será válida no futuro. Isso significa que, em certas alturas de bloco específicas, ainda é possível criar transações duplicadas. O próximo bloco onde podem ocorrer transações duplicadas é 1,983,702, previsto para ser gerado por volta de janeiro de 2046.
Apesar disso, o custo e a dificuldade de explorar esta vulnerabilidade são muito altos. Os mineradores não só precisam ter sorte suficiente para minerar um bloco específico, como também precisam gastar uma grande quantidade de taxas. Com o preço atual do Bitcoin, esse ataque pode custar mais de 15 milhões de dólares, e praticamente não tem utilidade prática.
Considerando a dificuldade de copiar transações, os custos e a escassez de oportunidades, essa vulnerabilidade não representa uma ameaça de segurança significativa para o Bitcoin. No entanto, dado a escala de tempo envolvida e a singularidade das transações repetidas, essa questão ainda é instigante. Os desenvolvedores de Bitcoin investiram muito tempo nesta questão ao longo dos anos, e 2046 pode ser o prazo final para corrigir essa vulnerabilidade de forma abrangente. A solução pode exigir um soft fork, sendo uma das possíveis abordagens a imposição do compromisso SegWit.