Confirmação

Alice envia a um amigo 20 000 sat, as menores unidades do bitcoin. A carteira mostra Enviado e o amigo já vê o pagamento a chegar, mas com zero confirmações. Não há contradição: a informação circulou entre nós, os computadores que verificam o Bitcoin, mas ainda não está num bloco. O Mempool é o conjunto local de transações não confirmadas de um nó, não uma fila única de toda a rede. Quando o pagamento entra num bloco aceite, recebe a primeira confirmação. O bloco seguinte dá a segunda, e o próximo a terceira. Alice não precisa de enviar nada outra vez. Difundir uma transação não a confirma, e o seu identificador txid também não o garante. Uma transação não confirmada pode ser substituída, por exemplo através de Replace-by-Fee (RBF), para aumentar a comissão. Aceitar um pagamento sem confirmação chama-se zero-conf e implica o risco de se confirmar antes outro gasto dos mesmos fundos. [4] [8] [11]

Um mineiro escolhe transações para um novo bloco e procura um Proof of Work válido, o resultado de cálculos dispendiosos exigido pelas regras do Bitcoin. Os restantes nós completos verificam depois o bloco por si próprios: as assinaturas, os montantes e as condições de gasto estão corretos, e os fundos ainda não foram gastos? Não se trata de uma votação dos mineiros nem do carimbo de uma empresa. Um mineiro não torna válido um pagamento inválido ao incluí-lo num bloco. O nó só o conta como confirmado na cadeia que aceita. Entre ramos válidos escolhe o que tem mais trabalho acumulado, chamado chainwork. Cada bloco referencia o anterior; alterar o passado exige, por isso, reconstruir também a sua continuação. [2] [7]

O Bitcoin procura uma média de dez minutos entre blocos, não um horário. Um novo bloco pode chegar em segundos ou muito mais tarde. Uma hora de espera não equivale, por si só, a seis confirmações. Uma taxa de comissão maior pode aumentar a probabilidade de o mineiro escolher a transação, mas não acelera a produção de blocos. Algumas carteiras permitem RBF, substituir uma transação não confirmada por outra com maior comissão, ou CPFP (Child Pays for Parent): uma transação dependente acrescenta comissões suficientes para compensar a inclusão conjunta com a antecessora. A disponibilidade depende da carteira e da transação. Uma comissão baixa pode significar uma longa espera ou a remoção da transação do Mempool de um nó. A estimativa da carteira é uma estimativa, não um prazo prometido. [3] [4]

O destinatário ou serviço determina quantas confirmações exige antes de aceitar o pagamento. Uma compra pequena pode justificar uma tolerância ao risco diferente da entrega irreversível de um bem caro. Se uma plataforma espera várias confirmações, a transação pode já estar na blockchain enquanto o saldo da conta ainda não foi creditado. Isso não significa automaticamente um erro. Verifique montante, destino e estado na carteira, bem como as condições de crédito do serviço. A fonte da informação também importa. Um atacante pode isolar um nó e apresentar-lhe uma visão limitada da rede: é uma Eclipse Attack. A espera adequada depende, portanto, do valor, das possibilidades de reparação, da confiança na outra parte e da forma de verificar. O número de confirmações, por si só, não protege de uma chave roubada. [11] [13]

Imagine o pagamento como um registo sobre o qual se acumulam novas páginas de história. Não basta alterar uma página antiga: um atacante teria de produzir uma continuação válida concorrente com trabalho acumulado suficiente. Nas condições habituais, as confirmações adicionais tornam isso mais difícil. Mas o resultado depende também da capacidade de cálculo do atacante e do estado da rede. As seis confirmações frequentemente citadas são uma referência histórica, não uma regra de consenso nem uma fronteira mágica de segurança total. Não existe uma probabilidade fixa de reescrita que descreva honestamente todas as situações. Mais confirmações também não corrigem um endereço errado nem um pagamento a um burlão. [1] [13]

Pode surgir uma bifurcação breve sem ataque quando dois mineiros encontram um bloco quase ao mesmo tempo. A passagem de um nó para outro ramo vencedor chama-se reorganização. Uma saída regista um montante e as condições para o gastar; uma entrada de uma transação posterior referencia essa saída e gasta-a. Uma saída ainda não gasta chama-se UTXO. Se um ramo válido concorrente acumular mais trabalho, ou seja, mais chainwork, o nó desliga os últimos blocos da cadeia anterior e liga o ramo vencedor. Uma transação de um bloco desligado pode regressar ao Mempool, se continuar válida, ou ser confirmada noutra altura. Também pode passar a estar em conflito se o novo ramo tiver gasto a mesma saída que uma das suas entradas referencia. Um valor negativo de confirmations no Bitcoin Core é a forma como a carteira indica a profundidade do conflito. Não significa um número negativo de blocos nas regras de consenso. [5] [7]

A altura do bloco é a sua posição na sequência, contada desde o bloco inicial com o número zero. Se o bloco da transação estiver na altura h e o último bloco da cadeia ativa do nó estiver na altura H, o número de confirmações é H − h + 1. O próprio bloco que contém a transação conta como o primeiro. O resultado depende do melhor bloco validado por esse nó e pode divergir por instantes entre nós quando chegam novos blocos. Não faz parte da transação, não aumenta apenas com a passagem do tempo e não se pode determinar de forma fiável a partir de uma marca temporal. O Bitcoin Core devolve dados como blockhash, blockheight e confirmations de acordo com o estado conhecido pela carteira correspondente ou pela sua visão dos UTXO. [3] [5] [6]

SPV significa verificação simplificada de pagamentos, enquanto RPC é uma interface de programação para consultar um nó. A diferença entre métodos importa mesmo quando duas aplicações mostram o mesmo número. Um nó completo valida a cadeia e responde de acordo com o fim atual da sua própria cadeia validada. Um cliente SPV verifica o Proof of Work nos cabeçalhos e a prova de inclusão de Merkle da transação, mas não verifica sozinho todas as regras de consenso. Uma prova de Merkle usa um pequeno conjunto de impressões digitais criptográficas para demonstrar que uma transação está incluída num bloco, sem descarregar todas as transações desse bloco. Um serviço que guarda fundos em nome do utilizador aplica também as suas próprias regras de crédito dos pagamentos e de gestão do risco. Mesmo o resultado de um RPC de um nó completo retrata o estado num dado momento, que uma reorganização pode alterar. Por isso, além do número de confirmações, importa em quem o utilizador confia para obter a visão da cadeia, a verificação e a custódia dos fundos. [1] [2] [8]

Uma Coinbase Transaction é a primeira transação especial de um bloco, que paga a recompensa ao mineiro; não tem relação com a plataforma Coinbase. Um bloqueio temporal limita quando se podem gastar os fundos. BIP identifica uma proposta técnica ou uma norma. A confirmação também inicia certos prazos do protocolo. Uma saída de uma transação coinbase está sujeita à regra COINBASE_MATURITY = 100: só pode ser gasta a partir de um bloco cuja altura seja 100 superior à do bloco dessa transação coinbase. É um período de espera obrigatório antes de gastar a recompensa do bloco, não uma escolha do destinatário de um pagamento comum. Os bloqueios temporais relativos de BIP68 partem da confirmação da saída que se pretende gastar e avaliam a sua idade segundo regras baseadas em blocos ou em tempo. Um script é um pequeno programa que define as condições para gastar uma saída. A instrução CHECKSEQUENCEVERIFY (CSV), definida em BIP112, permite impor essa condição relativa num script. Uma transação que gasta uma saída não confirmada continua a depender da transação que a criou. Para a transação dependente ser confirmada, as suas antecessoras têm de estar incluídas no mesmo bloco ou num bloco anterior. [9] [10]

Lightning Network permite pagamentos por canais financiados através de transações Bitcoin. BOLT designa as suas especificações técnicas; aqui trata-se da abertura de um canal, não de esperar por um bloco em cada pagamento dentro dele. BOLT 2 permite que a parte que aceita um canal Lightning indique, no campo minimum_depth, o número de confirmações que exige à transação de financiamento antes de enviar a mensagem channel_ready. Esta exigência tem em conta o risco de gasto duplo do financiamento. Um canal aberto sem confirmações, ou zero-conf channel, define minimum_depth como zero e apoia-se deliberadamente na confiança em quem fornece os fundos e nas restrições do protocolo. Não obtém assim uma liquidação instantânea e irreversível. Se a própria transação de financiamento for uma transação coinbase, BOLT 2 obriga a parte que não abre o canal a esperar pelo menos 100 blocos. O operador deve acompanhar a saída específica que financia o canal —o funding outpoint—, a sua profundidade na cadeia ativa e as reorganizações. A mera difusão de um txid ainda não significa que o canal esteja aberto. [12] [14]