O conflito pode ser observado antes mesmo do acordo, mas um gasto duplo bem-sucedido ocorre apenas quando a vítima gasta valor em uma transação e a outra ganha na cadeia recebida. Portanto, um pagamento de carteira substituído, um aumento não intencional de taxas ou um conflito malsucedido não são automaticamente fraudes. A corrida zero-conf e a substituição de blocos comprometidos têm custos e riscos fundamentalmente diferentes.
Cada entrada refere-se à saída anterior usando um txid e um índice. Duas transações estão em conflito quando pelo menos um insumo refere-se ao mesmo ponto final não gasto, mas não podem pagar ao mesmo tempo. Ao validar um bloco, o nó verifica se a entrada existe e se não foi gasta anteriormente no histórico determinado ou em outro lugar do mesmo bloco. Apenas uma ramificação sobrevive em um conjunto UTXO válido; o ataque não produz uma cópia do satoshi, ele tenta fazer com que o destinatário atue no galho que perde. [Whitepaper Bitcoin - Transações, Servidor de carimbo de data / hora e cálculos] [Guia do desenvolvedor Bitcoin - Transações] [Bitcoin Core - validação.cpp]
Não existe um mempool global ou uma ordem de consenso de transações não confirmadas antes da mineração. Os pares podem primeiro ver vários conflitos devido a promoção, topologia, política de taxas, status do pacote ou isolamento do eclipse. Visto pela primeira vez é uma política de retransmissão, não uma obrigação dos mineiros de confirmar a primeira opção. Um txid no backend do comerciante prova apenas que um candidato assinado chegou, e não que toda a rede o viu ou ganhou um bloco. [Guia do desenvolvedor Bitcoin – Processamento de pagamentos] [Bitcoin Core – Substituições de Mempool]
Substituir por taxa permite que um nó substitua conflitos de mempool que atendam às regras de taxa e anti-DoS; full-RBF tem sido a política padrão no Bitcoin Core desde a versão 28. O remetente pode aumentar legitimamente a taxa de pagamento bloqueado e preservar a saída do destinatário ou redirecionar o valor. Em ambos os casos, o consenso vê candidatos comuns e aceita a variante no histórico minado válido. Um sinal, substituição ou colisão RBF por si só não prova fraude; uma transação sem sinal novamente não é segura para zero-conf. [Bitcoin Core – Substituições de Mempool] [BIP 125 – Substituição total por taxa opcional]
Num ataque de corrida, o pagador envia uma transação ao comerciante e o conflito aos mineiros ou outros pares, para que o comerciante emita bens não retornáveis antes que o bloco selecione uma opção. O resultado depende da promoção, da visão de rede do comerciante, da escolha dos mineradores e do tempo de transferência. Ouvintes mais independentes melhorarão a detecção, mas não criarão uma finalidade determinística. Os nomes race, Finney e Vector76 são modelos de cenário, não matrizes de transação ou várias regras de consenso. [Guia do desenvolvedor Bitcoin - Processamento de pagamentos] [Karam et al. – Mau comportamento em Bitcoin]
Um invasor do tipo Finney com capacidade de minerar primeiro encontra o bloco que contém o conflito de forma privada, retornando o valor para ele, depois paga ao comerciante zero-conf com o mesmo UTXO e publica o bloco oculto após receber a mercadoria. O plano só terá sucesso se o bloco permanecer utilizável e for aceito pela rede antes que um bloco rival honesto frustre a preparação; o invasor arrisca tanto a recompensa do bloco quanto os custos de mineração. Esperar que a transação do comerciante seja incluída no bloco verificado encerra a sequência clássica, mas não elimina o risco de reorganização posterior. [Whitepaper Bitcoin – Transações, servidor de carimbo de data/hora e cálculos] [Karame et al. – Mau comportamento em Bitcoin]
Uma vez confirmado, o conflito não pode mais simplesmente empurrar o pagamento para fora do mempool: a agência alternativa válida deve pular o pagamento, incluir o segundo gasto e ganhar mais trabalho em cadeia do que a cadeia ativa do destinatário. Uma reorganização pode ocorrer mesmo sem fraude em blocos quase simultâneos ou um incidente de software ou rede; um gasto duplo bem-sucedido contra a vítima visa apenas ganhar valor ao vencer o conflito. O Bitcoin Core pode mostrar confirmações negativas e conflitos de carteira para uma transação de carteira perdida. [Bitcoin Core - Validação] [Bitcoin Core - validação.cpp] [Bitcoin Core RPC - gettransaction]
A parcela de hashrate do invasor, a profundidade de confirmação e o valor obtido determinam a corrida estocástica do trabalho privado e honesto. Abaixo de 50% não significa chance zero; A maioria permanente aumenta significativamente a possibilidade de recuperação, mas não permite que os mineiros falsifiquem assinaturas, gastem UTXO estrangeiro, excedam a emissão ou forcem nós completos a aceitar um bloco inválido. Os custos incluem hashpower, energia, perda de recompensas honestas, risco de perda, liquidez e exposição; a renda também pode incluir posições de mercado, portanto o mero preço do aluguel de máquinas não é suficiente. [Whitepaper do Bitcoin – Transações, servidor de carimbo de data/hora e cálculos] [Rosenfeld – Análise de gastos duplos baseados em taxa de hash] [Garay, Kiayias e Leonardos – O protocolo Bitcoin Backbone]
Cada commit adicional força a ramificação alternativa a refazer mais pendências e, dadas as suposições, reduz a probabilidade de sucesso. Não existe um número seguro universal: café, carro, depósito em bolsa e saque não reembolsável apresentam valor, motivação e possibilidade de correção diferentes. As seis afirmações frequentemente citadas são uma convenção, não um consenso. A política também deve monitorar a distribuição de hashrate, reorganizações incomuns, confiança no backend, risco de eclipse e reversibilidade de transferências. [Guia do desenvolvedor Bitcoin – Processamento de pagamentos] [Rosenfeld – Análise de gastos duplos baseados em taxa de hash]
O back-end pode monitorar gastos conflitantes do mempool em seu próprio nó completo, chamar gettxspendingprevout, ler conflitos de carteira, comparar dicas ativas e avisar sobre a perda de confirmação. Mais peers ou nós independentes reduzem os pontos cegos, mas a ausência de um conflito detectado é uma evidência fraca: um invasor pode interceptá-lo ou enviá-lo para outro lugar. O Explorer mostra uma visualização de nó personalizada e pode demorar. A detecção permite interromper a distribuição; ele não pode dizer aos mineiros para vencerem ou transformar o zero-conf em confirmação. [Bitcoin Core RPC – gettransaction] [Bitcoin Core RPC – gettxspendingprevout] [Karame et al. – Mau comportamento em Bitcoin]
Para liquidação onchain, valide com seu próprio nó completo, vincule o pedido com o txid exato, saídas e valor, defina a profundidade de acordo com a possível perda, em caso de reorganização ou conflito, interrompa o atendimento e separe o saldo creditado do valor sacável. Não trate um descendente de mudança não confirmado como independente do pai. A Lightning lida com pagamentos recorrentes rápidos de maneira diferente: um ponto final de financiamento confirmado ancora o canal e as regras de compromisso/revogação controlam o estado fora da cadeia; O canal zero-conf confia conscientemente no financiador e não elimina o risco de gasto duplo do financiamento. [BOLT 2 – Protocolo Peer] [Bitcoin Optech – Canais Zero-conf]
Para ter uma visão mais completa, leia este verbete junto com Transação, Confirmação, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. Também há referências a este verbete em Confirmação, Reorg, Stale Block, Replace-by-Fee (RBF).