Mastering Bitcoin
10. Minería y Consenso » Agregando Transacciones en los Bloques » Datos Coinbase
Página 71 de 98
Agregando Transacciones en los Bloques
Después de validar transacciones, un nodo bitcoin las añadirá al pool de memoria, o pool de transacciones, donde las transacciones quedan esperando hasta que puedan ser incluidas (minadas) en un bloque. El nodo de Jing recoge, valida, y retransmite nuevas transacciones al igual que cualquier otro nodo. Sin embargo, a diferencia de otros nodos, el nodo de Jing agregará estas transacciones en un bloque candidato.
Sigamos los bloques que se crearon durante el tiempo en que Alice compró una taza de café de Bob Cafe (ver el ejemplo sobre la taza de café). La transacción de Alice se incluyó en el bloque 277.316. Con el fin de demostrar los conceptos de este capítulo, vamos a suponer que el bloque fue minado por el sistema de minería de Jing y seguiremos la transacción de Alice, hasta que pasa a formar parte de este nuevo bloque.
El nodo de minería de Jing mantiene una copia local de la cadena de bloques, la lista de todos los bloques creados desde el comienzo del sistema bitcoin en 2009. Para cuando Alice compra la taza de café, el nodo de Jing ha montado una cadena hasta el bloque 277.314. El nodo de Jing está a la escucha de transacciones, tratando de explotar un nuevo bloque, y también a la escucha de bloques descubiertos por otros nodos. Mientras el nodo de Jing está minando, recibe el bloque 277.315 a través de la red Bitcoin. La llegada de este bloque significa el final de la competición para el bloque 277.315 y el comienzo de la competición para crear el bloque 277.316.
Durante los 10 minutos anteriores, mientras que el nodo de Jing estaba buscando una solución para el bloque 277.315, estaba al mismo tiempo recogiendo las transacciones en preparación para el siguiente bloque. Para entonces habrá recogido unos pocos cientos de transacciones en el pool de memoria. Al recibir el bloque 277.315 y validarlo, el nodo de Jing también comprobará todas las transacciones en el pool de memoria y retirará las que se hayan incluido en el bloque 277.315. Las transacciones que aún permanezcan en el pool de memoria seguirán sin confirmar y estarán esperando a ser registradas en un nuevo bloque.
El nodo de Jing construye de inmediato un nuevo bloque vacío, un candidato para el bloque 277.316.
Este bloque se denomina bloque candidato porque aún no es un bloque válido, ya que no contiene una prueba de trabajo válida. El bloque se vuelve válido sólo si el minero tiene éxito en la búsqueda de una solución para el algoritmo de prueba de trabajo.
Edad de Transacción, Comisiones, y Prioridad
Para construir el bloque candidato, el nodo bitcoin de Jing selecciona las transacciones del pool de memoria mediante la aplicación de una métrica de prioridad a cada transacción, agregando en primer lugar las transacciones de mayor prioridad. Las transacciones se priorizan en base a la «edad» de la UTXO que se gasta en las entradas, lo que permite que se dé preferencia a las entradas más antiguas y de alto valor frente a las entradas más nuevas y de menor valor. Las transacciones más prioritarias se pueden enviar sin comisiones, si hay suficiente espacio en el bloque.
La prioridad de una transacción se calcula como la suma del valor y la edad de las entradas dividido por el tamaño total de la transacción:
Prioridad = Sum (Valor de la entrada * Edad de la entrada) / Tamaño de Transacción
En esta ecuación, el valor de una entrada se mide en la unidad base, satoshis. Un bitcoin se compone de 100.000.000 «céntimos» que son los llamados satoshis). La edad de un UTXO es el número de bloques que han transcurrido desde que la UTXO se registró en la cadena de bloques, tomando como medida a cuántos bloques de «profundidad» está en la cadena de bloques. El tamaño de la transacción se mide en bytes.
Para que una transacción se considere de «alta prioridad», su prioridad debe ser superior a 57.600.000, lo que corresponde a un bitcoin (100 millones de satoshis), con una edad de un día (144 bloques), en una transacción de 250 bytes de tamaño en total:
Alta Prioridad > 100.000.000 satoshis * 144 bloques / 250
bytes
= 57.600.000
Los primeros 50 kilobytes de espacio de transacción en un bloque se reservan para las transacciones de alta prioridad. El nodo de Jing llenará los primeros 50 kilobytes, dando prioridad a las transacciones de mayor prioridad en primer lugar, independientemente de la comisión. Esto permite que las transacciones de alta prioridad puedan ser procesadas, incluso si llevan cero comisiones.
El nodo de minería de Jing entonces llena el resto del bloque hasta el tamaño de bloque máximo (MAX_BLOCK_SIZE en el código), con transacciones que llevan al menos la comisión mínima, dando prioridad a las que tienen la comisión más alta por kilobyte de transacción.
Si hay algún espacio restante en el bloque, el nodo de minería de Jing podría elegir llenarlo con las transacciones sin comisiones. Algunos mineros pueden esforzarse por añadir transacciones sin comisiones. Otros mineros pueden optar por ignorar las transacciones sin comisiones.
Cualquier transacción que quede en el pool de memoria, después de haberse llenado el bloque, permanecerá en el pool para su inclusión en el siguiente bloque. A medida que las transacciones permanecen en el pool de memoria, sus entradas se hacen cada vez más antiguas, ya que la UTXO gastada va obteniendo más profundidad en la cadena de bloques con los nuevos bloques adicionales que van añadiéndose en la parte superior. Debido a que la prioridad de una transacción depende de la edad de sus entradas, las transacciones que quedan en el pool envejecerán y por lo tanto aumentarán de prioridad. Con el tiempo, una transacción sin comisiones podría alcanzar la prioridad suficiente para ser incluida en el bloque de forma gratuita.
Las transacciones bitcoin no tienen fecha de caducidad. Una transacción que es válida ahora será válida para siempre. Sin embargo, si una transacción se propaga a través de la red una sola vez, persistirá solo mientras se mantenga en el pool de memoria de algún nodo de minería. Cuando se reinicia un nodo de minería, su pool de memoria se vacía, porque se trata de almacenamiento no persistente. Aunque una transacción válida se haya propagado a través de la red, si no se ejecuta, puede que eventualmente deje de residir en el pool de memoria de cualquier minero. El software de cartera debería retransmitir este tipo de transacciones o reconstruirlas con comisiones más altas si no se ejecutan con éxito dentro de un plazo razonable de tiempo.
Cuando el nodo de Jing agrega todas las transacciones del pool de memoria, el nuevo bloque candidato tiene 418 operaciones con un total en comisiones de transacción de 0,09094928 bitcoin. Puede ver este bloque en la cadena de bloques utilizando la interfaz de línea de comandos del cliente Bitcoin Core, como se muestra en el ejemplo Bloque 277.316.
$ bitcoin-cli getblockhash 277316
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
$ bitcoin-cli getblock
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
Ejemplo 3. Bloque 277.316
{
"hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
"confirmations" : 35561,
"size" : 218629,
"height" : 277316,
"version" : 2,
"merkleroot": "c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e",
"tx" : [
"d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
"B268b45c59b39d759614757718b9918caf0ba9d97c56f3b91956ff877c503fbe",
… 417 transacciones más …
],
"time" : 1388185914,
"nonce" : 924591752,
"bits" : "1903a30c",
"difficulty" : 1180923195.25802612,
"chainwork" : "000000000000000000000000000000000000000000000934695e92aaf53afa1a",
"previousblockhash" :
"0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569",
"nextblockhash" :
"000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
}
La Transacción Generación
La primera transacción añadida al bloque es una transacción especial, llamada transacción de generación o transacción coinbase. Esta transacción es construida por el nodo de Jing y es su recompensa por el esfuerzo de la minería. El nodo de Jing crea la transacción de generación como un pago a su propia cartera: «Pague a la dirección de Jing 25,09094928 bitcoins». La cantidad total de recompensa que Jing recibe por haber minado un bloque es la suma de la recompensa coinbase (25 nuevos bitcoins) y las comisiones de transacción (0,09094928) de todas las transacciones incluidas en el bloque como se muestra en Generación de Transacciones:
$ bitcoin-cli getrawtransaction
d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1
Ejemplo 4. Generación de Transacciones
{
"hex" :
"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f\
03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f\
329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
"txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"coinbase" : "03443b0403858402062f503253482f",
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 25.09094928,
"n" : 0,
"scriptPubKey" : {
"asm" :
"02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21OP_CHECKSIG",
"hex" :
"2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N"
]
}
}
],
"blockhash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
"confirmations" : 35566,
"time" : 1388185914,
"blocktime" : 1388185914
}
A diferencia de las transacciones normales, la transacción de generación no consume (gasta) UTXO como entradas. En su lugar, solo tiene una entrada, llamada el coinbase, que crea bitcoin de la nada. La transacción de generación tiene una salida, que paga a la propia dirección bitcoin del minero. La salida de la transacción de generación envía el valor de 25,09094928 bitcoins a la dirección bitcoin del minero, en este caso 1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N.
Recompensa de Coinbase y Comisiones
Para construir la transacción de generación, el nodo de Jing primero calcula el importe total de las comisiones por transacciones mediante la suma de todas las entradas y salidas de las 418 transacciones que se han añadido al bloque. Las comisiones se calculan como:
Total Comisiones = Suma(Entradas) - Suma(Salidas)
En el bloque 277.316 el total de comisiones de transacción es de 0,09094928 bitcoins.
A continuación, el nodo de Jing calcula la recompensa correcta para el nuevo bloque. La recompensa se calcula en base a la altura del bloque, comenzando por los 50 bitcoins por bloque y reduciendo a la mitad cada 210.000 bloques. Debido a que este bloque está a la altura de 277.316, la recompensa correcta es de 25 bitcoins.
El cálculo se puede ver en la función GetBlockSubsidy del cliente Bitcoin Core, como se muestra en Calculando la recompensa de bloque — Función GetBlockSubsidy, Cliente Bitcoin Core, main.cpp.
Ejemplo 5. Calculando la recompensa de bloque — Función GetBlockSubsidy, Cliente Bitcoin Core, main.cpp
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
// Forzar la recompensa de bloque a cero cuando desplazamiento a la derecha no está definido.
if (halvings >= 64)
return 0;
CAmount nSubsidy = 50 * COIN;
// La recompensa se reduce a la mitad cada 210.000 bloques que se producirán aproximadamente cada 4 años.
nSubsidy >>= halvings;
return nSubsidy;
}
La recompensa inicial se calcula en satoshis multiplicando 50 por la constante COIN (100.000.000 satoshis). Esto establece la recompensa inicial (nSubsidy) a 5 mil millones de satoshis.
A continuación, la función calcula el número de halvings que se han producido («halving» es un término en inglés que significa «reducción a la mitad»). Para ello, la función divide la altura del bloque actual por el intervalo de «halving» (SubsidyHalvingInterval). En el caso del bloque 277.316, con un intervalo de «halving» cada 210.000 bloques, el resultado es 1 «halving».
El número máximo de «halvings» permitido es 64, por lo que el código impone una recompensa cero (retorna solo las comisiones) si se superan los 64 «halvings».
A continuación, la función utiliza el operador de desplazamiento-derecha-binario para dividir la recompensa (nSubsidy) entre dos para cada ronda de «halving». En el caso del bloque 277.316, se haría un único desplazamiento binario hacia la derecha de la recompensa de 5 mil millones de satoshis (un «halving») dejando como resultado 2,5 mil millones de satoshis o 25 bitcoins. Se utiliza el operador desplazamiento-binario-derecha porque es más eficiente para dividir entre dos que la división de números enteros o de punto flotante.
Finalmente, se añade la recompensa coinbase (nSubsidy) a las comisiones de transacción (nFees), y se devuelve la suma.
Estructura de la Transacción Generación
Con estos cálculos, el nodo de Jing construye después la transacción de generación, pagándose a sí mismo 25,09094928 bitcoin. Como se puede ver en Generación de Transacciones, la transacción de generación tiene un formato especial. En lugar de una entrada de transacción que especifica una UTXO anterior para ser gastado, tiene una entrada de «coinbase». Examinamos las entradas de transacción en el apartado al efecto. Vamos a comparar una entrada de transacción normal con una entrada de transacción de generación. La estructura de una entrada de transacción «normal» muestra la estructura de una transacción normal, mientras que La Estructura de una entrada de transacción de generación muestra la estructura de entrada de la transacción de generación.
Tabla 1. La estructura de una entrada de transacción «normal»
Tabla 2. La Estructura de una entrada de transacción de generación
En una transacción de generación, los dos primeros campos se establecen en valores que no representan una referencia UTXO. En lugar de un «Hash Transacción», el primer campo se rellena con 32 bytes todos a cero. El «Índice de Salida» se rellena con 4 bytes todos a 0xFF (255 decimal). El «Script de Desbloqueo» se sustituye por los datos coinbase, un campo de datos arbitrario utilizado por los mineros.
Datos Coinbase
Las transacciones de generación no tienen un campo para script de desbloqueo (scriptSig). En cambio, este campo se sustituye por los datos coinbase, que deben ser de entre 2 y 100 bytes. A excepción de los primeros bytes, el resto de los datos coinbase pueden ser utilizados por los mineros en cualquier forma que deseen; se trata de datos arbitrarios.
En el bloque de génesis, por ejemplo, Satoshi Nakamoto añadió el texto «The Times 03/Jan/2009 Chancellor on brink of second bailout for banks» (traducido al español: «The Times 03/Ene/2009 Canciller preparado para segundo rescate a los bancos») en los datos coinbase, usándolo como una prueba de la fecha y para transmitir un mensaje. Actualmente, los mineros utilizan los datos coinbase para incluir valores nonce adicionales y cadenas que identifican el pool de minería, como veremos en las siguientes secciones.
Los primeros bytes del coinbase solían ser arbitrarios, pero ya no es así. Según la Propuesta de Mejora Bitcoin 34 (BIP0034), los bloques de versión-2 (bloques cuyo campo de versión se establece en 2) deben contener el índice de altura del bloque como un script de operación «push» en el principio del campo coinbase.
En el bloque 277.316 vemos que el coinbase (ver Generación de Transacciones), que está en el «Script de Desbloqueo» o en el campo scriptSig de la entrada de transacción, contiene el valor hexadecimal 03443b0403858402062f503253482f. Vamos a decodificar este valor.
El primer byte, 03, indica al motor de ejecución de scripts que empuje los siguientes tres bytes en la pila de script (ver el apartado sobre «Muestra operadores para poner los valores en la pila»). Los siguientes tres bytes, 0x443b04, son la altura del bloque codificado en formato little-endian (hacia atrás, byte menos significativo primero). Invertiendo el orden de los bytes, el resultado sería 0x043b44, que es 277.316 en decimal.
Los siguientes dígitos hexadecimales (03858402062) se utilizan para codificar un nonce extra (ver La Solución de Nonce Extra), o valor aleatorio, que se utiliza para encontrar una solución adecuada a la prueba de trabajo.
La parte final de los datos coinbase (2f503253482f) es la cadena codificada en ASCII /P2SH/, que indica que el nodo de minería que extrae este bloque apoya la mejora pago-a-hash-de-script (P2SH) definida en BIP0016. La introducción de la capacidad P2SH requirió un «voto» por los mineros para respaldar ya fuese BIP0016 o BIP0017. Aquellos que respaldaron la implementación BIP0016 incluyeron /P2SH/ en sus datos coinbase. Aquellos que respaldaron la implementación BIP0017 de P2SH incluyeron la cadena p2sh/CHV en sus datos coinbase. El BIP0016 fue elegido como el ganador, y muchos mineros continuaron incluyendo la cadena /P2SH/ en su coinbase para indicar el apoyo a esta funcionalidad. Extraer los datos coinbase del bloque génesis utiliza la biblioteca libbitcoin introducida en el apartado sobre Libbitcoin para extraer los datos coinbase del bloque génesis que muestran el mensaje de Satoshi.
Tenga en cuenta que la biblioteca libbitcoin contiene una copia estática del bloque génesis, por lo que el código de ejemplo puede recuperar el bloque génesis directamente desde la biblioteca.
Ejemplo 6. Extraer los datos coinbase del bloque génesis
/*
Display the genesis block message by Satoshi.
*/
#include <iostream>
#include <bitcoin/bitcoin.hpp>
int main()
{
// Create genesis block.
bc::block_type block = bc::genesis_block();
// Genesis block contains a single coinbase transaction.
assert(block.transactions.size() == 1);
// Get first transaction in block (coinbase).
const bc::transaction_type& coinbase_tx = block.transactions[0];
// Coinbase tx has a single input.
assert(coinbase_tx.inputs.size() == 1);
const bc::transaction_input_type& coinbase_input = coinbase_tx.inputs[0];
// Convert the input script to its raw format.
const bc::data_chunk& raw_message = save_script(coinbase_input.script);
// Convert this to an std::string.
std::string message;
message.resize(raw_message.size());
std::copy(raw_message.begin(), raw_message.end(), message.begin());
// Display the genesis block message.
std::cout << message << std::endl;
return 0;
}
Compilamos el código con el compilador GNU C++ y lanzamos el ejecutable resultante, como se muestra en Compilando y ejecutando el código de ejemplo satoshi-words.
Ejemplo 7. Compilando y ejecutando el código de ejemplo satoshi-words $ # Compilando el código
$ g++ -o satoshi-words satoshi-words.cpp $(pkg-config --cflags --libs libbitcoin) $ # Ejecutar el ejecutable
$ ./satoshi-words
^D GS^A^DEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks