Transacción coinbase

Imaginemos a Ana preparando un bloque candidato para minar. Reúne pagos de usuarios y coloca delante una transacción especial que indica quién recibirá la recompensa. En nuestro ejemplo, las reglas permiten crear 3,125 BTC y los pagos seleccionados aportan 0,075 BTC en comisiones. Ana puede reclamar como máximo 3,2 BTC. Esa primera transacción es coinbase. Escribirla no basta para ganar la recompensa: el bloque debe cumplir el requisito de minería y todas las demás condiciones, que los nodos receptores verifican por sí mismos. Si reclama demasiado, rechazan el bloque completo, por mucha energía que haya gastado en encontrarlo. No hay una cuenta central que le envíe el dinero. Las nuevas monedas nacen bajo reglas compartidas dentro de un bloque aceptado. De los 3,2 BTC del ejemplo, solo 3,125 BTC son nuevos; el resto lo pagaron los usuarios. Es una recompensa, no un beneficio neto: aún no hemos descontado los costes de minería. [6] [4]

La emisión nueva permitida se llama Block Subsidy y se reduce periódicamente a la mitad con el Halving. Un satoshi es la unidad mínima de bitcoin. Las comisiones dependen de los pagos concretos incluidos, por lo que dos bloques pueden ofrecer recompensas distintas. El límite es la emisión nueva correspondiente a la altura, calculada por GetBlockSubsidy en Bitcoin Core, más las comisiones de las demás transacciones válidas del bloque. Solo la emisión aumenta la cantidad de bitcoin; las comisiones son satoshis existentes. El minero puede cobrar menos, pero no recuperar después la diferencia: la emisión no reclamada nunca nace y las comisiones no cobradas quedan para siempre sin posibilidad de gasto. Un solo satoshi de más invalida todo el bloque. [4] [6]

La recompensa suele ir a un pool, que coordina el trabajo de varios mineros. Un script de bloqueo es un pequeño programa que establece las condiciones para gastar una salida. PPS, FPPS y PPLNS son distintos métodos con los que los pools distribuyen los ingresos entre participantes. Las salidas usan scripts de bloqueo ordinarios. La recompensa puede ir a una dirección común, repartirse entre destinatarios o reservar una parte al operador del pool. Los nodos verifican importes y condiciones de gasto, no contratos ni titulares reales. PPS, FPPS, PPLNS, mínimos de pago y transferencias posteriores a participantes son reglas del pool, no del consenso de Bitcoin. [6] [7]

Ana puede ver la recompensa en el bloque, pero todavía no pagar la electricidad con ella. No la retiene un exchange: la espera la imponen las reglas de Bitcoin. La altura es el número de posición de un bloque; H indica aquí la altura del bloque en el que se creó la recompensa. COINBASE_MATURITY exige una diferencia mínima de 100 entre la altura del bloque que gasta la salida y la de su creación. Una salida nacida en H puede gastarse por primera vez en un bloque válido H+100. El contador de confirmaciones puede parecer distinto porque ya incluye el bloque creador. Importa la diferencia de alturas, no una estimación en horas. Cumplirla no garantiza que el bloque nunca salga de la cadena. [5]

Una reorganización hace que el nodo pase a otra rama válida con más trabajo de minería acumulado. Los UTXO son salidas sin gastar, es decir, importes disponibles individuales. Una recompensa puede desaparecer de ese registro junto con su bloque. Una reorganización puede retirar el bloque original de la cadena válida activa con más trabajo acumulado. Sus salidas coinbase desaparecen entonces del conjunto UTXO activo. También pueden verse afectadas transacciones que gasten la recompensa. Esperar 100 bloques limita el impacto de reorganizaciones cortas, pero no ofrece una garantía absoluta. El pool debe distinguir recompensa activa, posibilidad de gasto y obligaciones propias con los mineros. [4] [5]

Para describir el formato hacen falta algunos nombres: una entrada suele señalar fondos que se gastan; una salida fija un importe y sus condiciones de gasto. El txid identifica la transacción, la versión determina su formato y locktime puede limitar cuándo se incluye. Todo bloque debe contener al menos una transacción; solo la primera puede ser coinbase. Tiene una única entrada con una referencia nula a una salida anterior: un hash de 32 bytes cero y el índice 0xffffffff. Esa referencia, llamada outpoint, no gasta nada previo, por lo que no se comprueba una firma ordinaria que autorice ese gasto. La transacción sí conserva txid, versión, locktime y una o más salidas. [1] [2] [3]

La altura es el número de posición del bloque. BIP34 identifica una propuesta cuya regla adoptó Bitcoin; scriptSig es un campo de la entrada y CScript representa instrucciones y números de scripts. BIP34 exige que scriptSig empiece con la altura del bloque como número CScript con codificación mínima. El campo completo ocupa 2–100 bytes. Después caben una extra nonce, una identificación del pool o datos de minería fusionada. Una altura o longitud incorrecta causa el rechazo. Aunque la entrada no se ejecuta como un script normal de desbloqueo, sus códigos de operación de firma pueden contar para el límite sigops, que limita el número de operaciones de firma. [1] [9]

La minería calcula repetidamente un hash, la huella digital del resumen del bloque llamado cabecera. Un nonce es un número que se modifica y la raíz de Merkle resume las transacciones. Cambiar una transacción abre nuevos intentos. El nonce de la cabecera tiene 32 bits y los equipos agotan rápidamente sus posibilidades. El programa cambia también una extra nonce en coinbase: cambian el txid, la raíz de Merkle y la cabecera, abriendo otro espacio de búsqueda de hashes. El pool reparte el trabajo entre equipos para evitar que prueben innecesariamente las mismas variantes. La extra nonce no crea monedas adicionales. [6] [7] [12]

SegWit separa ciertos datos de verificación, como firmas, en una parte llamada witness. Un commitment vincula datos de forma verificable; no es otro pago. El formato siguiente sirve como referencia técnica de ese vínculo. Si el bloque contiene datos witness, BIP141 exige una salida coinbase con un witness commitment, una vinculación criptográfica con esos datos. Su script empieza por 6a24aa21a9ed: OP_RETURN, inserción de 36 bytes y marca aa21a9ed. Sigue un hash doble SHA-256 de 32 bytes de la raíz de Merkle witness concatenada con el valor reservado. El witness de la entrada coinbase debe contener únicamente ese valor reservado de 32 bytes. Si coinciden varias salidas, se toma el índice mayor. No es un pago gastable; sin datos witness en el bloque, el commitment es opcional. [10]

Un Full Node es un ordenador que verifica las reglas de Bitcoin por sí mismo. El peso mide el uso de la capacidad de datos permitida en el bloque; el Mempool guarda localmente transacciones normales sin confirmar. Verificar la recompensa forma parte de verificar todo el bloque. Un Full Node exige coinbase en primer lugar y rechaza cualquier coinbase adicional en ese bloque. Comprueba scriptSig, altura BIP34, límites de importes, peso del bloque, comisiones y el witness commitment necesario. La suma de salidas no puede superar emisión permitida más comisiones; el gasto posterior debe respetar la madurez. El minero no puede adjudicarse válidamente cualquier cantidad. Sin su bloque, coinbase no entra en el Mempool. [3] [4] [10]

Genesis Block es el bloque inicial de Bitcoin. Su situación especial y los identificadores repetidos del pasado explican por qué no se deben aplicar indiscriminadamente las reglas actuales a todos los casos históricos. Antes de exigir la altura, distintas coinbase podían tener el mismo txid. BIP30 impide sobrescribir salidas antiguas aún no gastadas; BIP34 añade una altura diferenciadora en los bloques modernos ordinarios. Genesis Block es especial: contiene su coinbase, pero la inicialización no convirtió su salida en gastable. Por eso los 50 BTC originales no se pueden gastar; no es una espera normal de 100 bloques. [8] [9] [11]