Finality é o caráter definitivo da liquidação: até que ponto podemos confiar que uma transferência concluída se manterá? O Bitcoin oferece uma segurança probabilística que aumenta com mais trabalho válido. Nenhum número universal de confirmações, por si só, exclui uma mudança de ramo da cadeia ou determina o cumprimento jurídico de todo um acordo.
Inicialmente, Paulo vê apenas que a carteira tomou conhecimento da transação. Isso não equivale à sua inclusão num bloco. Quando esse bloco existe e outros são acrescentados sobre ele, substituir o histórico exige superar cada vez mais trabalho. É assim que a Finality aumenta na prática. Também contam os recursos de um possível atacante e o estado da rede. O protocolo não emite um certificado matemático de irreversibilidade; cabe ao destinatário avaliar a força das provas para aceitar aquele pagamento. [1] [2]
Um Full Node verifica autonomamente as regras do Bitcoin. Não aceita um histórico só por ser longo. Primeiro verifica a validade e depois escolhe, entre os ramos válidos, aquele com maior trabalho acumulado. Trata-se do trabalho demonstrado pelos blocos, não de uma votação por pessoas ou quantidade de moedas. Mais trabalho não torna válida uma transação inválida. Paulo precisa de saber as duas coisas: se o pagamento respeita as regras e a que profundidade se encontra no histórico válido atualmente seguido. [1]
No nosso exemplo, a transação de Paulo está no bloco de altura 800000, e o último bloco do mesmo ramo tem altura 800005. A altura indica a posição do bloco, não uma hora. O cálculo é 800005 − 800000 + 1 = 6 confirmações, incluindo o próprio bloco da transação. Não se contam apenas os blocos posteriores. Se o pagamento estiver somente no mempool, o conjunto de transações não confirmadas daquele nó, tem 0 confirmações. A passagem do tempo, por si só, não aumenta o contador. [2] [3]
A rede pode conhecer brevemente blocos concorrentes e depois continuar noutro ramo válido com mais trabalho. Essa mudança do histórico ativo chama-se reorganização. Na documentação do Bitcoin Core 28.0, a consulta do cabeçalho getblockheader devolve confirmations = -1 quando o bloco está fora da cadeia ativa. O valor descreve o bloco, não a perda automática de todos os seus pagamentos. A transação de Paulo pode estar também no novo ramo, aguardar sem confirmação ou entrar em conflito com outra. É necessário voltar a verificar o seu estado concreto. [1] [3]
O guia para programadores menciona 6 confirmações como limiar habitual para pagamentos de valor elevado, explicando também a necessidade de avaliar o risco. É uma regra de aceitação do destinatário, não uma mudança no consenso do Bitcoin. Paulo deve considerar o valor da bicicleta, a perda possível e a fiabilidade da verificação; o número não decide por ele. Uma média de aproximadamente uma hora também não significa que seis blocos cheguem sempre numa hora. A mineração não tem horário fixo, e uma recomendação geral antiga não garante todos os casos. [2]
Paulo pode ter BTC confirmados e continuar a discutir a entrega ou o estado da bicicleta. Os PFMI, princípios internacionais para infraestruturas dos mercados financeiros, exigem um momento de liquidação definitiva claramente definido e um limite a partir do qual um participante não pode revogar uma instrução. É um enquadramento diferente da contagem de blocos do Bitcoin. As confirmações não determinam, por si só, o efeito jurídico de um contrato, a liquidação definitiva de um pagamento bancário ou a transferência de propriedade. Verificar o pagamento não substitui as restantes condições do negócio. [4]
Se Paulo e o comprador acordarem um reembolso, este faz-se normalmente por uma nova transação enviada por quem recebeu o pagamento original. A transferência anterior mantém-se no histórico. O Bitcoin não tem um apoio central com um botão para cancelar pagamentos confirmados a pedido. Uma reorganização altera o histórico ativo da rede; não é um serviço de atendimento para corrigir enganos. Por isso, deve verificar-se o destinatário e o montante antes do envio. Esperar mais confirmações não corrige um pagamento mal introduzido. [5]
Para quem opera uma aplicação de pagamentos, o trabalho não termina na aceitação. É necessário registar a transação, o bloco e a fonte de verificação, e detetar se o nó ficou atrasado em relação à rede. confirmations representa o estado no momento da consulta, não um certificado permanente. Se a contagem diminuir ou surgir um conflito, a aplicação precisa de regras previamente definidas e de uma nova verificação do ramo ativo. Uma captura de ecrã antiga não é uma prova nova. Paulo deve decidir pelo estado atual do pagamento, não apenas pelo que a carteira mostrou antes. [2] [3]
Para ter uma visão mais completa, leia este verbete junto com Confirmação, Proof of Work, Settlement risk, Delivery versus payment. Também há referências a este verbete em Byzantine Generals Problem, Delivery versus payment.