Gasto duplo

Imagine que Tomás tem uma saída recebida anteriormente de 100 000 sat, as menores unidades do bitcoin. Uma saída ainda não gasta se chama UTXO. Ele prepara um pagamento de 99 000 sat para Alice, deixando 1 000 sat como taxa. Mas também poderia assinar outra transação que gastasse o mesmo UTXO e mandasse o dinheiro para outro destino. As duas usam a mesma origem dos fundos e, por isso, entram em conflito. Não é como copiar um arquivo: um nó Bitcoin, computador que verifica as regras, não permite gastar a mesma saída duas vezes em uma cadeia válida. A fraude teria sucesso se Alice entregasse o produto pelo primeiro pagamento, mas o histórico aceito acabasse contendo o segundo. Não surgiram novas moedas; Alice confiou na versão que perdeu. Tecnicamente, cada entrada indica uma saída anterior pelo identificador de sua transação, txid, e pelo número da saída. Esse par é chamado de outpoint. [1] [3] [7]

Alice pode ver um pagamento chegando em poucos segundos. Isso não significa que ele já entrou em um bloco. O Mempool é o conjunto local de transações não confirmadas de um nó. Não existe um Mempool global nem uma ordem de chegada comum a toda a rede Bitcoin. Outro nó pode ter recebido primeiro a versão conflitante ou ainda nem ter visto a de Alice. A política first-seen favorece a primeira versão recebida ao retransmitir transações. Não promete que um minerador a incluirá em um bloco. Uma captura da carteira ou um txid, isoladamente, não comprovam a liquidação. O que importa é o estado daquele pagamento em uma cadeia verificada de maneira confiável. [2] [5]

Alice também pode estar enviando um pagamento legítimo que espera há muito tempo. Replace-by-Fee (RBF) permite substituir uma transação não confirmada, normalmente por outra com taxa maior. O destinatário pode receber o mesmo valor apesar da mudança do txid. A substituta usa ao menos parte dos mesmos fundos e, portanto, conflita tecnicamente com a original sem que ninguém tente enganar o destinatário. Importam o conteúdo do novo pagamento e as circunstâncias, não apenas a marca RBF. O mesmo mecanismo, porém, também permite redirecionar o dinheiro. Full-RBF é a política padrão do Bitcoin Core desde a versão 28 e não exige que a transação inicial sinalize a possibilidade de substituição. A substituta ainda precisa cumprir as regras de taxas e proteção contra abusos do nó. Assim, a ausência de sinalização RBF também não torna irreversível um pagamento não confirmado. [5] [6] [15]

Um pagamento ganha uma confirmação quando entra em um bloco válido aceito pelo nó. Os blocos seguintes normalmente dificultam substituir esse histórico e reduzem o risco de fraude. Entretanto, não existe uma quantidade segura para todas as situações. Perder o valor de um café difere de entregar um carro ou liberar um grande saque de uma corretora. As seis confirmações frequentemente citadas são uma convenção, não uma regra do Bitcoin. É preciso considerar o valor, as formas de reparar uma perda, comportamentos incomuns da cadeia e a qualidade da informação. Isolar um nó, em um Eclipse Attack, pode distorcer sua visão da rede. Esperar deve acompanhar a verificação, não substituí-la. [2] [10]

A mudança de um nó para outra ramificação válida se chama reorganização. Proof of Work comprova o trabalho necessário para produzir blocos; o trabalho acumulado de uma ramificação é chamado de chainwork. Depois da confirmação, a transação conflitante já não pode simplesmente expulsar o pagamento do Mempool. Uma ramificação alternativa válida precisa excluir o pagamento original, incluir o outro gasto e acumular mais trabalho, ou chainwork, que a cadeia ativa do destinatário. Uma reorganização também pode ocorrer sem fraude, por exemplo quando blocos são minerados quase ao mesmo tempo ou há uma falha de software ou de rede. Só há gasto duplo bem-sucedido contra a vítima quando o atacante obtém valor porque a transação conflitante prevaleceu. Para a transação perdedora da carteira, o Bitcoin Core pode exibir um número negativo de confirmações no campo confirmations e os conflitos relacionados no campo walletconflicts. [4] [7] [8]

Hashrate é a velocidade dos cálculos de mineração. Uma participação maior ajuda na disputa pelo histórico, mas não dispensa as outras regras. A chance de uma ramificação minerada em segredo alcançar a cadeia honesta depende, entre outros fatores, da parcela do poder computacional da rede controlada pelo atacante e do número de confirmações. O valor que ele poderia obter influencia principalmente se o ataque compensa. Uma participação inferior a 50 % não significa chance zero; manter uma maioria aumenta muito a possibilidade de alcançar a outra ramificação. Nem mesmo essa maioria permite aos mineradores falsificar assinaturas, gastar UTXO alheios, violar as regras de emissão ou obrigar nós completos a aceitar um bloco inválido. Ao avaliar um ataque, é preciso considerar o poder computacional, a energia e as recompensas que deixam de ser recebidas por não minerar honestamente. Também importam o capital disponível, o risco de fracasso e a possibilidade de ser descoberto. O retorno também pode incluir ganhos de posições nos mercados financeiros, por isso apenas o preço de alugar máquinas de mineração não basta para estimá-lo. [1] [10] [12]

Race se refere aqui a uma corrida de tempo: o destinatário e os mineradores podem ver primeiro transações diferentes. Em um race attack, o pagador envia uma transação ao comerciante e uma transação conflitante aos mineradores ou a outros nós. Seu objetivo é fazer o comerciante entregar a mercadoria de forma irreversível antes de um bloco selecionar uma das variantes. O resultado depende da propagação das transações, da visão da rede que o comerciante tem, da seleção dos mineradores e do momento da entrega. Vários nós independentes observando a rede melhoram a detecção de conflitos, mas não garantem uma liquidação irreversível. Os nomes race, Finney e Vector76 descrevem cenários de ataque, não campos de dados da transação nem regras de consenso distintas. [2] [11]

Finney attack é o nome de um cenário em que o atacante também controla capacidade de mineração. Não é o aumento normal de taxa de uma carteira. Em um Finney attack, um atacante com capacidade de mineração primeiro minera, em privado, um bloco com a transação conflitante que devolve o valor a ele. Depois paga com o mesmo UTXO a um comerciante que aceita pagamentos não confirmados e publica o bloco oculto após receber a mercadoria. O plano só funciona se o bloco continuar utilizável e a rede o aceitar antes que um bloco concorrente honesto inviabilize a preparação. O atacante arrisca tanto a recompensa do bloco quanto os custos de mineração. Esperar que a transação do comerciante entre em um bloco validado interrompe essa sequência clássica, mas não elimina o risco de uma reorganização posterior da cadeia. [1] [11]

RPC é a interface de programação do nó. Os nomes abaixo são comandos e campos para desenvolvedores de sistemas de pagamento, não outro tipo de confirmação. O sistema do comerciante pode monitorar gastos conflitantes no Mempool de seu próprio nó completo, chamar gettxspendingprevout, ler o campo walletconflicts, comparar o último bloco da cadeia ativa e alertar para a perda de confirmações. Mais nós conectados ou independentes reduzem os pontos cegos, mas a ausência de um conflito detectado é uma evidência fraca de segurança: o atacante pode reter a transação conflitante ou enviá-la por outro caminho. Um explorador de blocos mostra a visão de seu próprio nó e pode estar atrasado. A detecção permite interromper a entrega da mercadoria. Ela não pode obrigar os mineradores a escolher uma transação nem tornar um pagamento não confirmado equivalente a um confirmado. [8] [9] [11]

Confira o pagamento que realmente chegou, seu destino, valor e confirmações. O comprovante do remetente não substitui essa conferência. Um nó completo próprio permite verificar as regras diretamente. Ao usar um serviço de terceiros, entenda de quem dependem suas informações e, quando aplicável, a custódia. Um sistema comercial deve vincular o pedido a saídas específicas e acompanhar substituições. Um conflito ou a perda de confirmações deve interromper uma entrega irreversível. Outro pagamento que gaste troco não confirmado depende da transação original: não é uma prova independente de segurança. Lightning Network permite pagamentos rápidos em canais financiados por transações Bitcoin. Os participantes trocam transações commitment assinadas que registram a divisão dos fundos. Ao atualizar o canal, entregam à outra parte dados secretos que permitem uma penalização caso publiquem depois um estado ultrapassado; essa invalidação do estado anterior se chama revocation. A proteção depende de detectar a tentativa e reagir a tempo. É um mecanismo diferente de entregar mercadoria por uma transferência não confirmada na cadeia. Um canal aberto sem confirmação, ou zero-conf channel, confia deliberadamente em quem o financia e não elimina o risco de gasto duplo desse financiamento. [13] [14]