O que é Bitcoin?

Explicação completa e didática

1) Definição resumida

Bitcoin é um sistema de dinheiro eletrônico peer-to-peer que permite transferir valor sem intermediário central, baseado em um livro-razão distribuído chamado blockchain. A ideia original e o protocolo foram descritos por Satoshi Nakamoto no whitepaper de 2008.

bitcoin.org

Ele garante consenso global usando Proof-of-Work (PoW) (hashing SHA-256) e um conjunto de regras (consenso) que todos os nós verificam.

developer.bitcoin.org

A unidade de conta mínima é o satoshi (1 BTC = 100.000.000 satoshis) e o suprimento total é limitado a 21 milhões de bitcoins (emissão programada por halving).

bitcoin.org

2) Origem e propósito

Em outubro de 2008 Satoshi Nakamoto publicou “Bitcoin: A Peer-to-Peer Electronic Cash System”, propondo resolver o problema do double spending sem autoridade central, usando um registro encadeado de blocos e prova de trabalho. Esse whitepaper é a referência original do protocolo.

bitcoin.org

3) Visão de alto nível — como as partes se encaixam

Usuários criam transações (assinadas com suas chaves privadas).

Transações entram na mempool (pool de transações não confirmadas) e são retransmitidas em um overlay P2P.

Mineradores agrupam transações em blocos e competem para produzir um bloco válido resolvendo o puzzle de PoW (hash do cabeçalho do bloco menor ou igual a um alvo). O minerador vencedor propaga o bloco e recebe recompensa (bloco + taxas).

developer.bitcoin.org

Todos os nós completos (full nodes) verificam cada bloco/transação segundo regras de consenso; somente blocos válidos são aceitos na melhor cadeia.

developer.bitcoin.org

4) Dados fundamentais — blocos, cabeçalho, Merkle e prova de trabalho

Bloco e cabeçalho

Um bloco contém um conjunto de transações e um cabeçalho de 80 bytes que inclui, entre outros campos: version, previous block hash, merkle root (compromisso das TXs), time, nBits (alvo compactado) e nonce. O hash duplo SHA-256 do cabeçalho deve ser ≤ target para o bloco ser válido (prova de trabalho).

developer.bitcoin.org

Merkle tree

O merkle root sintetiza todas as TXIDs do bloco em uma árvore de hashes. Isso permite provas de inclusão compactas (SPV proof): um nó leve pode verificar que uma transação está em um bloco recebendo apenas um caminho de hashes até o merkle root.

developer.bitcoin.org

Proof-of-Work

O PoW em Bitcoin usa SHA-256(SHA-256()) (double SHA-256) sobre o cabeçalho. Mineradores iteram o nonce (e outros campos modificáveis) para encontrar um cabeçalho cujo hash seja menor/igual ao alvo (target) implícito em nBits. Esse trabalho vincula custo computacional à produção de blocos, tornando reescrever história caro.

developer.bitcoin.org

Ajuste de dificuldade

A dificuldade é ajustada a cada 2.016 blocos (aprox. 14 dias). Se os últimos 2.016 blocos foram minerados em menos tempo que o ideal, a dificuldade sobe; se demorou mais, a dificuldade cai (com limites de variação por retarget). Isso mantém o intervalo médio entre blocos próximo a ~10 minutos.

developer.bitcoin.org

5) Transações e o modelo UTXO (Unspent Transaction Output)

O que é uma transação

No Bitcoin, uma transação consome UTXOs (saídas não gastas) e cria novas saídas. Uma saída especifica um valor (satoshis) e uma locking script (scriptPubKey) que define a condição para gastar aquela saída; o gasto é feito por uma transação que fornece uma unlocking script (scriptSig) e/ou dados de testemunha.

developer.bitcoin.org

UTXO vs contas

Bitcoin usa o modelo UTXO (sem estado de conta global): cada saída não gasta é um “objeto” que representa saldo. Isso facilita paralelismo, auditoria e verificação local do que um cliente possui (verificando que as UTXOs estão sob sua chave). Contrasta com o modelo “account” (como Ethereum) que mantém saldos por endereço.

Formato bruto e TXID

As transações são serializadas em um formato bruto (raw tx) e o TXID é o hash (double SHA-256) da forma serializada sem witness (em pre-SegWit). SegWit introduziu distinção entre txid e wtxid (witness tx id) — importante para maleabilidade e para identificar transações contendo dados de testemunha separados.

developer.bitcoin.org

Wikipédia

Verificação

Para cada entrada:

verificar que o UTXO referenciado existe e está disponível;
verificar que a assinatura(s) corresponde(m) à(s) chave(s) exigida(s) pelo locking script (Script evaluation);
garantir que as somas de entradas ≥ somas de saídas (diferença = taxas).

Todo full node executa essas verificações antes de aceitar/relatar a transação.

developer.bitcoin.org

6) Script — a “linguagem” de Bitcoin (contratos)

Bitcoin tem uma linguagem de scripts (stack-based, inspirada em Forth) desenhada para ser não-Turing-completa (sem loops), mais simples e previsível. Ela fornece primitivas como OP_CHECKSIG, OP_HASH160, OP_DUP, OP_EQUALVERIFY, etc. Isso permite construir condicionais simples (multisig, timelocks) e contratos básicos.

developer.bitcoin.org

Tipos de saída comuns:

P2PKH (legacy): Pay to Public Key Hash — endereços que começam com 1.
P2SH: Pay to Script Hash — endereços que começam com 3 (redeem script separado).
SegWit: P2WPKH / P2WSH (endereços bc1... em Bech32) — testemunha separada, resolve malleability e melhora eficiência.

GitHub

Bitcoin Optech

7) Chaves, assinaturas e características criptográficas

Chaves

Cada carteira controla pares de chaves (privada, pública) usando a curva elíptica secp256k1. A chave pública (ou seu hash) aparece em scripts e endereços; a chave privada assina transações. Bibliotecas como libsecp256k1 são implementações robustas dessa curva.

GitHub

Assinaturas ECDSA → Schnorr/Taproot

Tradicionalmente o Bitcoin usava ECDSA (secp256k1) para assinaturas. Nas melhorias recentes, BIP-340 / Schnorr e BIP-341 (Taproot) foram adotados (soft-fork em 2021), trazendo assinaturas Schnorr (mais compactas, linearidade útil para agregação) e Taproot (melhor privacidade de scripts, possibilidade de key path e script path de gasto). Essas mudanças ampliam expressividade e eficiência das transações sem quebrar compatibilidade com versões antigas.

GitHub

8) Evoluções importantes do protocolo (ex.: SegWit e Taproot)

Segregated Witness (SegWit) — BIP141

SegWit (2017) separou as assinaturas (witness) do corpo principal da transação, corrigiu a maleabilidade de assinaturas (permitindo aplicações off-chain como Lightning), e introduziu uma métrica de “peso” para blocos (em vez do limite rígido de 1MB). Endereços nativos SegWit usam Bech32 (BIP173).

GitHub

Taproot + Schnorr — BIPs 340–342

Taproot (2021) + Schnorr aproximam transações complexas (multisig, scripts) de transações simples em termos de privacidade e tamanho, porque assinaturas e scripts podem ser combinados/agregados. Isso melhora privacidade e eficiência de contratos on-chain.

GitHub

9) Wallets, HD wallets e gestão de chaves

Carteiras podem ser custodiais (serviço guarda chaves) ou non-custodial (você controla chaves). Há também hardware wallets para segurança das chaves privadas.

BIP-32 define carteiras hierárquicas determinísticas (HD wallets) — permite derivar muitas chaves de uma seed. BIP-39 define a mnemonic seed (frases de 12/24 palavras) para backup humano. BIP-44 padroniza caminhos de derivação (m/44`'`/0`'`/0`'`/...). Esses BIPs são padrões amplamente usados por carteiras modernas.

GitHub

10) Propagação P2P, mempool e inclusão em bloco

Transações são anunciadas e retransmitidas pela rede P2P (gossip), os nós mantêm políticas (por exemplo: taxa mínima de relay). Transações aguardam na mempool até serem incluídas em blocos pelos mineradores. Ferramentas de estimação de tarifa analisam mempool e histórico para sugerir feerates que aumentem chance de inclusão.

developer.bitcoin.org

Bitcoin Optech

Existem técnicas como Replace-By-Fee (RBF — BIP125) e Child-Pays-For-Parent (CPFP) para “bump” de taxas quando necessário (políticas e suporte variam entre carteiras e nós).

11) Escalabilidade e camadas (Lightning)

A camada 1 (on-chain) tem capacidades limitadas (por decisão de desenho e segurança). Para micropagamentos e alta escalabilidade, existe a Lightning Network (Layer-2): canais de pagamento (state channels), roteamento de pagamentos e protocolos especificados nos BOLTs (Basis of Lightning Technology). Lightning permite milhares de txs off-chain com apenas poucas transações on-chain para abrir/fechar canais.

GitHub

12) Privacidade e suas limitações

Bitcoin é pseudônimo: endereços não vinculam automaticamente à identidade humana, mas o ledger é público e permanente — análises on-chain (clustering, heurísticas, KYC de exchanges) frequentemente vinculam transações a identidades.

Técnicas de privacidade incluem CoinJoin, CoinSwap, e melhores práticas de carteira (endereços únicos, evitar reutilização). Mesmo assim, privacidade completa demanda cuidado e design especializado. (ver documentação e discussões técnicas sobre proteção de privacidade).

learnmeabitcoin.com

mempool.space

13) Segurança, ataques e limites do modelo

Double-spend e confirmações: antes de considerar dinheiro “final”, comerciantes costumam aguardar várias confirmações (6 é uma referência histórica), porque uma cadeia alternativa com mais trabalho poderia eventualmente anular blocos recentes. O risco decresce exponencialmente com número de confirmações, mas é probabilístico — não existe “imediata finalidade absoluta”.

developer.bitcoin.org

Ataque 51%: um agente controlando >50% da taxa de hashing pode reescrever história (custo alto). Economicamente, esse ataque é caro e destrói confiança/valor, então há forças econômicas dissuasoras, mas o risco técnico existe enquanto o atacante tiver capacidade de hashing maior que a rede.

developer.bitcoin.org

14) Economia da emissão — halving e recompensa

Recompensa de bloco: os mineradores recebem uma recompensa fixa por bloco que diminui pela metade aproximadamente a cada 210.000 blocos (≈4 anos). Começou em 50 BTC por bloco (2009), passou para 25, 12.5, 6.25 (a última halving foi em 2020). O protocolo define um limite final de 21 milhões de BTC; após isso, mineradores dependem de taxas de transação.

bitcoin.org

15) Governança e mudanças no protocolo

Mudanças no protocolo são propostas como BIPs (Bitcoin Improvement Proposals). Atualizações que não quebram consenso podem ser soft-forks; outras requerem coordenação maior. A governança é distribuída: desenvolvedores propõem, operadores/mineradores e economia (exchanges, nós, usuários) realizam adoção. Exemplos: SegWit (BIP141) e Taproot (BIPs 340–342).

GitHub

16) Como verificar ou usar o Bitcoin de forma prática (princípios operacionais)

Full node

Full node: baixa e valida toda a blockchain; provê máxima segurança e privacidade (você verifica regras por si mesmo).

SPV / light client

SPV / light client: valida por cabeçalhos e provas de Merkle (mais leve, menos segurança).

Carteiras

Carteiras: ao usar uma carteira não custodial, guarde a seed (BIP39) com segurança; prefira hardware wallets para grandes valores.

developer.bitcoin.org

GitHub

17) Recomendações práticas e “melhores práticas”

Para segurança: mantenha backups off-line da seed, prefira hardware wallets para valores grandes, use endereços diferentes por recebimento (evita linkabilidade).

Para pagamentos/recebimentos: aguarde confirmações adequadas (depende valor/risco) — pequenas compras podem aceitar 0-conf com risco controlado (mas é técnico e arriscado).

Para desenvolvedores: teste em testnet/regtest, rode um node completo para validação, e leia o Developer Guide e BIPs antes de projetar integração.

developer.bitcoin.org

18) Referências (para leitura técnica e verificação)

Whitepaper (Satoshi Nakamoto) — A Peer-to-Peer Electronic Cash System.

bitcoin.org

Bitcoin Developer Documentation (block headers, merkle, P2P, transações): developer.bitcoin.org (Block Chain, Transactions, P2P, Mining).

developer.bitcoin.org

FAQ e conceitos econômicos — bitcoin.org/faq (21M cap, halving explanation).

bitcoin.org

SegWit (BIP141) e Bech32 (BIP173) — BIPs e documentação relacionada.

GitHub - github.com/bitcoin/bips/blob/master/bip-0116.mediawiki?.com

Github - github.com/bitcoin/bips/blob/master/bip-0173.mediawiki?.com

Taproot / Schnorr (BIPs 340–342) — repositório BIPs (especificações).

GitHub - github.com/bitcoin/bips?.com

Lightning Network (BOLTs) — especificações da camada-2.

GitHub - github.com/lightning/bolts?.com

Fee estimation / mempool — Bitcoin-Optech, mempool.space e estudos sobre fee-estimators.

Bitcoin Optech

mempool.space

19) Conclusão — por que Bitcoin funciona (resumido)

Bitcoin combina:

um ledger público imutável (blockchain),
um mecanismo de parceira que exige custo real para escrever nova história (PoW),
regras de consenso verificáveis por qualquer nó, e
mecanismos criptográficos para autorização (chaves e assinaturas).

O design produz uma rede resistente, distribuída e audível — com trade-offs (escala, latência, privacidade) que foram endereçados com melhorias graduais (SegWit, Taproot) e com soluções em camadas (Lightning).