Coinbase é um tipo de transação consensual, não uma empresa Coinbase ou um pagamento regular. Junto com o bloco, o node verifica ponto outpoint zero, altura conforme BIP34, teto de recompensa, posição zero, maturidade e possível comprometimento do SegWit. Não é aceito no mempool separadamente.
Um bloco deve conter pelo menos uma transação e a coinbase só pode ser a primeira. O Bitcoin Core o reconhece por sua estrutura exata: uma única entrada com 32 zero bytes no hash da saída anterior e um índice de 0xffffffff. A entrada não desbloqueia um UTXO existente, portanto não possui uma assinatura regular ou valor anterior. Uma transação ainda pode ter múltiplas saídas, uma versão regular, bem como um tempo de bloqueio e um txid personalizado. [Referência do desenvolvedor Bitcoin - entrada Coinbase] [Referência do desenvolvedor Bitcoin - Cadeia de blocos] [Bitcoin Core - transaction.h (IsCoinBase)]
A soma dos resultados da coinbase não pode exceder GetBlockSubsidy para esse valor mais as taxas de todas as outras transações válidas no bloco. Apenas o componente de recompensa recém-emitido cria novo satoshi; taxas convertem satoshi pré-existente. Um minerador pode reivindicar menos e a diferença desaparece para sempre, mas um único satoshi acima do limite invalida todo o bloco. O consenso não determina a divisão entre um pool, mineradores ou vários scripts. [Bitcoin Core — validação.cpp] [Bitcoin Core — miner.cpp]
A partir do BIP34, o scriptSig coinbase deve começar com a altura do bloco atual como um número CScript minimamente codificado. O scriptSig inteiro tem de 2 a 100 bytes. O restante pode conter um nonce extra, uma tag de pool ou um compromisso de mineração mesclado, mas não está fora das regras: uma altura ou comprimento incorreto invalidará o bloco, e os opcodes de assinatura incorporados podem consumir o limite do sigop. [Referência do desenvolvedor Bitcoin - entrada Coinbase] [BIP 34 - Altura do bloco em coinbase]
O ASIC altera o nonce no cabeçalho, mas o espaço de 32 bits acaba rapidamente. O software de mineração, portanto, transforma o nonce extra em uma base de moedas; isso mudará seu txid, a transação raiz Merkle e subsequentemente o cabeçalho do bloco, para que ele obtenha um novo espaço de hash. Os protocolos de pool dividem esse espaço entre os trabalhadores para que suas ações não colidam. O nonce extra é uma peça de coordenação, não uma emissão extra. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate] [Stratum V2 — Especificação do protocolo de mineração]
As saídas da Coinbase usam scripts de bloqueio comuns e podem ser divididas entre vários endereços ou políticas. O pool pode pagar para um endereço de cobrança, dividir a receita imediatamente ou reservar a saída para a operadora. No entanto, o nó verifica valores e scripts, não contratos ou proprietários reais. Limites de pagamento, PPS, FPPS, PPLNS e saques posteriores são regras de pool não protocoladas. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate]
Se o bloco contiver uma transação testemunha, o BIP141 exigirá um compromisso testemunha coinbase em uma saída: OP_RETURN começando com 6a24aa21a9ed e um compromisso de 32 bytes. A testemunha de entrada coinbase contém um único valor reservado de 32 bytes. Se houver mais resultados correspondentes, o consenso assume o índice mais alto. Esta saída vincula a raiz Merkle testemunha; não é uma recompensa para os mineiros. [BIP 141 – Compromisso de Testemunha Segregada]
A saída da coinbase é marcada com uma bandeira especial no conjunto UTXO e só poderá ser gasta quando a diferença entre a altura dos gastos e a criação dos blocos atingir COINBASE_MATURITY, hoje 100. Portanto, a recompensa da altura H pode ser gasta pela primeira vez no bloco H+100. A carteira pode mostrar uma aparente diferença de uma confirmação porque o bloco gerador conta primeiro. Maturidade não é finalidade. [Bitcoin Core — consenso.h (COINBASE_MATURITY)]
Se um bloco minerado sair da cadeia ativa com mais trabalho durante a reorganização, suas saídas coinbase desaparecerão do conjunto UTXO ativo. As transações subsequentes que já gastaram a recompensa vencida também podem ser inválidas. Um atraso de 100 blocos limita os danos de reorganizações curtas, mas não garante a imutabilidade. Um pool deve monitorar separadamente a cadeia ativa, a maturidade e seus compromissos com os mineradores. [Bitcoin Core — validação.cpp] [Bitcoin Core — consenso.h (COINBASE_MATURITY)]
O nó completo requer coinbase na posição zero durante a validação, rejeita coinbase adicional, verifica o comprimento do scriptSig e a altura do BIP34, calcula taxas de outras transações e rejeita recompensa acima da nova emissão mais taxas. Também verifica faixas de valor, peso, comprometimento de testemunhas e posterior vencimento dos gastos. Uma coinbase separada sem altura e contexto de bloco não pertence ao mempool. [Bitcoin Core — transaction.h (IsCoinBase)] [Bitcoin Core — validação.cpp] [BIP 141 — Compromisso de testemunha segregada]
Nos primeiros blocos, a mesma base de moedas txid poderia ser criada porque a altura ainda não era obrigatória. O BIP30 evita que a saída não gasta de uma transação mais antiga seja substituída, e o BIP34 torna as bases de moedas modernas geralmente uma altura única. Genesis é uma exceção histórica: sua base de moedas está em um bloco serializado, mas o código de inicialização nunca coloca sua saída no banco de dados UTXO descartável. Portanto, os famosos 50 BTC não podem ser gastos. [BIP 30 — Transações duplicadas] [BIP 34 — Altura do bloco na coinbase] [Bitcoin Core — chainparams.cpp (construção de gênese)]
Para ter uma visão mais completa, leia este verbete junto com Bloco, Recompensa de emissão do bloco, Taxas de transação, Mineração, Block Template, Bitcoin. Também há referências a este verbete em Recompensa de emissão do bloco, Confirmação, Reorg, Stale Block.