Coinbase es un tipo de transacción consensual, no una empresa Coinbase ni un pago regular. Junto con el bloque, el nodo verifica el punto de salida cero, la altura según BIP34, el techo de recompensa, la posición cero, la madurez y el posible compromiso de SegWit. No se acepta en el mempool por separado.
Un bloque debe contener al menos una transacción y coinbase solo puede ser la primera. Bitcoin Core lo reconoce por su estructura exacta: una única entrada con 32 bytes cero en el hash de la salida anterior y un índice de 0xffffffff. La entrada no desbloquea un UTXO existente, por lo que no tiene una firma regular ni un valor de salida previa. Una transacción aún puede tener múltiples resultados, una versión normal, así como un tiempo de bloqueo y un txid personalizado. [Referencia de desarrollador de Bitcoin: entrada de Coinbase] [Referencia de desarrollador de Bitcoin: cadena de bloques] [Núcleo de Bitcoin: transacción.h (IsCoinBase)]
La suma de los resultados de coinbase no puede exceder GetBlockSubsidy por ese monto más las tarifas de todas las demás transacciones válidas en el bloque. Sólo el componente de recompensa recién emitido crea nuevos satoshi; las tarifas convierten satoshi preexistente. Un minero puede reclamar menos y la diferencia desaparece para siempre, pero un solo satoshi por encima del límite invalida todo el bloque. El consenso no determina la división entre un grupo, mineros o múltiples scripts. [Bitcoin Core — validation.cpp] [Bitcoin Core — miner.cpp]
A partir de BIP34, scriptSig coinbase debe comenzar con la altura del bloque actual como un número CScript mínimamente codificado. El scriptSig completo tiene entre 2 y 100 bytes. El resto puede llevar un nonce adicional, una etiqueta de grupo o un compromiso de minería fusionado, pero no está fuera de las reglas: una altura o longitud incorrecta invalidará el bloque, y los códigos de operación de firma incorporados pueden consumir el límite de sigop. [Referencia del desarrollador de Bitcoin: entrada de Coinbase] [BIP 34: altura del bloque en Coinbase]
El ASIC cambia el nonce en el encabezado, pero el espacio de 32 bits se agota rápidamente. Por lo tanto, el software de minería convierte el nonce adicional en una base de monedas; esto cambiará su txid, la transacción raíz de Merkle y posteriormente el encabezado del bloque, por lo que obtiene un nuevo espacio hash. Los protocolos del pool dividen este espacio entre los trabajadores para que sus acciones no choquen. El nonce extra es una pieza de coordinación, no una emisión extra. [Bitcoin Core - miner.cpp] [BIP 22 - getblocktemplate] [Stratum V2 - Especificación del protocolo de minería]
Las salidas de Coinbase utilizan scripts de bloqueo comunes y se pueden dividir entre varias direcciones o políticas. El pool puede pagar a una dirección de cobro, dividir los ingresos inmediatamente o reservar la salida para el operador. Sin embargo, el nodo verifica cantidades y guiones, no contratos ni propietarios reales. Los umbrales de pago, PPS, FPPS, PPLNS y retiros posteriores son reglas del grupo sin protocolo. [Bitcoin Core - miner.cpp] [BIP 22 - getblocktemplate]
Si el bloque contiene una transacción testigo, BIP141 requiere un compromiso testigo de Coinbase en una salida: OP_RETURN que comienza con 6a24aa21a9ed y un compromiso de 32 bytes. El testigo de entrada de coinbase contiene un único valor reservado de 32 bytes. Si hay más resultados coincidentes, el consenso toma el índice más alto. Esta salida vincula la raíz testigo de Merkle; No es una recompensa para los mineros. [BIP 141 — Compromiso de testigos segregados]
La salida de coinbase está marcada con una bandera especial en el conjunto UTXO y se puede gastar solo cuando la diferencia entre la altura de los bloques de gasto y creación alcanza COINBASE_MATURITY, hoy 100. Por lo tanto, la recompensa de la altura H se puede gastar por primera vez en el bloque H+100. La billetera puede mostrar una diferencia aparente de una confirmación porque el bloque generador cuenta primero. La madurez no es finalidad. [Núcleo de Bitcoin - consenso.h (COINBASE_MATURITY)]
Si un bloque minado sale de la cadena activa con mayor trabajo durante la reorganización, sus salidas de base de monedas desaparecerán del conjunto UTXO activo. Las transacciones posteriores que ya hayan gastado la recompensa vencida también pueden no ser válidas. Un retraso de 100 bloques limita el daño de las reorganizaciones cortas, pero no garantiza la inmutabilidad. Un pool debe monitorear por separado la cadena activa, la madurez y sus compromisos con los mineros. [Bitcoin Core — validación.cpp] [Bitcoin Core — consenso.h (COINBASE_MATURITY)]
El nodo completo requiere una base de monedas en la posición cero durante la validación, rechaza una base de monedas adicional, verifica la longitud del scriptSig y la altura de BIP34, calcula las tarifas de otras transacciones y rechaza la recompensa por encima de las nuevas emisiones más las tarifas. También verifica rangos de valor, peso, compromiso de testigo y vencimiento posterior del gasto. Una base de monedas separada sin altura ni contexto de bloque no pertenece al mempool. [Bitcoin Core — transacción.h (IsCoinBase)] [Bitcoin Core — validation.cpp] [BIP 141 — Compromiso de testigo segregado]
En los primeros bloques, se pudo crear la misma base de monedas txid porque la altura aún no era obligatoria. BIP30 evita que se sobrescriba el resultado no gastado de una transacción anterior, y BIP34 hace que las bases de monedas modernas comúnmente tengan una altura única. Génesis es una excepción histórica: su base de monedas está en un bloque serializado, pero el código de inicialización nunca puso su salida en la base de datos UTXO prescindible. Por tanto, los famosos 50 BTC no se pueden gastar. [BIP 30 - Transacciones duplicadas] [BIP 34 - Altura del bloque en coinbase] [Bitcoin Core - chainparams.cpp (construcción génesis)]
Para obtener la imagen más completa, lee esta entrada junto con Bloque, Subsidio de bloque, Comisiones de transacción, Minería, Block Template, Bitcoin. También enlazan con esta entrada Subsidio de bloque, Confirmación, Nonce.