37 / 691CONF

Confirmação

Uma confirmação Bitcoin é a profundidade de uma transação na cadeia atualmente ativa e totalmente verificada de um nó específico: a inclusão em um bloco é uma confirmação, e cada bloco subsequente válido adiciona outra. Não é um voto, um recibo ou um selo irrevogável; a reorganização pode reduzir ou zerar o número.

A contagem de commits é um estado derivado, não um campo armazenado na transação. Se uma transação estiver em um bloco de altura h e a ponta da cadeia ativa for H, sua profundidade será H − h + 1. Uma transação no mempool tem zero commits; O Bitcoin Core pode exibir um valor negativo para uma transação de carteira conflitante, indicando a profundidade do conflito.

O envio não é uma confirmação. Cada nó aplica independentemente a política de admissão ao seu mempool, e diferentes nós podem ver um conjunto diferente devido a tempo, taxas, conflitos, limites de pacote ou configurações. A RBF pode substituir uma transação não confirmada e o pagamento visto pelo lojista pode desaparecer sem entrar no bloco. Portanto, o zero-conf negocia velocidade pelo risco de gastos duplos e de uma visão de rede incompleta; Nem o txid nem a página do explorer são assentamentos. [Guia do desenvolvedor Bitcoin - Transações] [Bitcoin Core - Consistência JSON-RPC] [BIP 125 - Substituição total por taxa de aceitação]

Um minerador pode selecionar uma transação em um bloco candidato, mas a primeira confirmação ocorre somente quando o nó de validação aceita o bloco e o bloco está em sua cadeia ativa com a maior cadeia. Full node verifica comprovação de trabalho, scripts, existência e não gasto de insumos, valores e demais regras de consenso; um minerador não pode resgatar um gasto inválido simplesmente listando. A raiz Merkle confirma a transação no bloco e uma referência ao bloco anterior a coloca no histórico de prova de trabalho. [Bitcoin Core – Validação] [Bitcoin Core – validação.cpp]

Se o bloco de transação estiver na altura h e a ponta atual do nó for H, a contagem será H − h + 1: o próprio bloco será contado primeiro. O valor é gerado em relação ao bloco melhor verificado desse nó, portanto a dica pode variar ligeiramente entre os nós. Não está escrito em uma transação, não cresce com o tempo e não pode ser determinado de forma confiável a partir de um carimbo de data/hora. Bitcoin Core retorna blockhash, blockheight e confirmações como o estado da carteira ou visualização UTXO. [Guia do desenvolvedor Bitcoin - Block Chain] [Bitcoin Core RPC - gettransaction] [Bitcoin Core RPC - getbestblockhash]

Se um ramo válido concorrente obtiver mais cadeias, o nó irá separar os blocos da ponta antiga e anexar o ramo vencedor. Uma transação de um bloco desanexado pode retornar ao mempool se permanecer válida, ser confirmada em um nível diferente ou entrar em conflito porque uma nova ramificação gastou a mesma entrada. As confirmações negativas no Bitcoin Core são uma convenção de carteira para profundidade de conflito, não blocos negativos de consenso. [Bitcoin Core RPC – gettransaction] [Bitcoin Core – validação.cpp]

Confirmações adicionais adicionam prova de trabalho para uma transação, normalmente tornando-a mais cara e improvável de reescrever o histórico. Eles não criam uma finalidade determinística. Tanto o cálculo de atualização do whitepaper quanto os modelos posteriores dependem da parcela de hashrate do invasor, do comportamento da rede honesta e das observações do receptor. “Seis Confirmações” é um dispositivo histórico, não uma constante de consenso ou um limite seguro universal; uma reorganização profunda ainda é possível em princípio. [Whitepaper Bitcoin – Prova de Trabalho e Cálculos] [Rosenfeld – Análise de Gastos Duplos Baseados em Taxa de Hash]

A contagem é exigida pelo destinatário, pela exchange ou pelo protocolo downstream, e não pela transação em si. Café, emissão não retornável de bens caros, depósito em bolsa e abertura de canal apresentam diferentes taxas de perda e espera. A política deve levar em consideração o valor, reversibilidade de desempenho, motivação e hashrate do atacante, conflitos ou RBF, custódia e backend, risco de eclipse e estado incomum da cadeia. A confirmação mitiga o risco de sobrescrever a cadeia; não consertará uma chave roubada, endereço errado ou fraude de contraparte. [BIP 125 – Substituição total por taxa de adesão] [Rosenfeld – Análise de gastos duplos baseados em taxa de hash]

O Bitcoin visa uma média de cerca de dez minutos entre os blocos, mas as chegadas de prova de trabalho são aleatórias: o próximo bloco pode chegar em segundos ou horas. Uma taxa mais alta pode melhorar a ordem de seleção dos mineradores e a economia dos pacotes RBF ou CPFP, mas nenhuma taxa compra um tempo fixo e não acelera a criação de blocos. Uma transação barata pode esperar muitos blocos ou ser removida do mempool; uma estimativa é uma probabilidade, não um prazo. [Guia do desenvolvedor Bitcoin – Block Chain] [Guia do desenvolvedor Bitcoin – Transações]

O nó completo valida a string e responde de acordo com sua própria dica ativa. O cliente SPV verifica a prova de trabalho nos cabeçalhos e na inclusão da prova Merkle, mas não executa todas as regras de consenso; o serviço de custódia também agrega política própria de crédito e risco. Até mesmo o resultado RPC de um nó completo é um instantâneo que pode ser alterado por reorganização. Portanto, a questão não é apenas “quantas confirmações”, mas também em qual visão em cadeia, validação e custódia o usuário confia. [Whitepaper Bitcoin – Prova de Trabalho e Cálculos] [Bitcoin Core – Validação] [Bitcoin Core – Consistência JSON-RPC]

Outras aulas também começam com confirmação. A saída da Coinbase está sujeita a COINBASE_MATURITY = 100 e só pode ser gasta após 100 novos blocos; esta é uma regra diferente da política de pagamento normal. Os timelocks relativos do BIP68, aplicados pelo script BIP112 CHECKSEQUENCEVERIFY (CSV), medem a idade do bloco de confirmação de saída. Um pai não confirmado mantém os descendentes dependentes; para que uma criança seja afirmada, seus ancestrais devem estar no mesmo bloco ou em um bloco mais antigo. [Bitcoin Core — consenso.h] [BIP 112 — CHECKSEQUENCEVERIFY]

O BOLT 2 permite que um receptor de canal Lightning escolha transações de financiamento de mínimo_profundidade antes de channel_ready; o número valoriza o financiamento de risco de gasto duplo. Um canal zero-conf define a profundidade mínima como zero e depende conscientemente da confiança do fundo e das restrições de protocolo, em vez da finalidade imediata. O financiamento da Coinbase está pendente de matrícula. A operadora deve monitorar o ponto final de financiamento, profundidade na cadeia ativa e reorganizações, não considerar o txid enviado como um canal aberto. [BOLT 2 – Protocolo Peer] [Bitcoin Optech – Canais Zero-conf]

Para ter uma visão mais completa, leia este verbete junto com Bloco, Transação, Reorg, Gasto duplo, Proof of Work, Bitcoin. Também há referências a este verbete em Gasto duplo, Transação coinbase, Reorg, Stale Block.

DOC · 001Bitcoin whitepaper — Proof-of-Work and CalculationsDocumentação ↗DOC · 002Bitcoin Core — ValidationDocumentação ↗DOC · 003Bitcoin Developer Guide — Block ChainDocumentação ↗DOC · 004Bitcoin Developer Guide — TransactionsDocumentação ↗DOC · 005Bitcoin Core RPC — gettransactionDocumentação ↗DOC · 006Bitcoin Core RPC — getbestblockhashDocumentação ↗DOC · 007Bitcoin Core — validation.cppDocumentação ↗DOC · 008Bitcoin Core — JSON-RPC consistencyDocumentação ↗DOC · 009Bitcoin Core — consensus.hDocumentação ↗DOC · 010BIP 112 — CHECKSEQUENCEVERIFYEspecificação ↗DOC · 011BIP 125 — Opt-in Full Replace-by-FeeEspecificação ↗DOC · 012BOLT 2 — Peer ProtocolEspecificação ↗DOC · 013Rosenfeld — Analysis of Hashrate-Based Double SpendingDocumentação ↗DOC · 014Bitcoin Optech — Zero-conf channelsDocumentação ↗
Revisado em 1º de agosto de 2026Fontes em primeiro lugar · Não é recomendação de investimento