Mastering Bitcoin
10. Minería y Consenso » Verificación Independiente de Transacciones
Página 69 de 98
Verificación Independiente de Transacciones
En el apartado sobre transacciones, vimos cómo el software de cartera crea transacciones mediante la recopilación de UTXO, proporcionando los scripts de desbloqueo apropiados, y construyendo después nuevas salidas asignadas a un nuevo propietario. La transacción resultante se envía entonces a los nodos vecinos en la red bitcoin de manera que se pueda propagar a través de toda la red bitcoin.
Sin embargo, antes de remitir las transacciones a sus vecinos, cada nodo bitcoin que recibe una transacción primero verifica la transacción. Esto garantiza que sólo las transacciones válidas se propaguen a través de la red, mientras que las transacciones no válidas se descartan en el primer nodo que las encuentra.
Cada nodo verifica cada transacción a través de una larga lista de criterios:
La sintaxis de la transacción y su estructura de datos deben ser correctos.
Ni las listas de entradas ni de salidas estén vacías.
El tamaño de la transacción en
bytes
es inferior a MAX_BLOCK_SIZE.
Cada valor de salida, así como el total, deben estar dentro del rango permitido de valores (menos de 21 millones de monedas, más de 0).
Ninguna de las entradas tiene de hash=0, N=-1 (transacciones coinbase no deben ser transmitidas).
nLockTime
es menor o igual a INT_MAX.
El tamaño de la transacción en
bytes
es mayor o igual a 100.
El número de operaciones de firma contenidas en la transacción es menor que el límite de operación de firma.
El script de desbloqueo (
scriptSig
) solo puede empujar números en la pila, y el script de bloqueo (
scriptPubKey
) debe respetar los formatos
isStandard
(esto rechaza transacciones «no estándar»).
Una transacción coincidente en el pool, o en un bloque en la rama principal, debe existir.
Para cada entrada, si existe la salida de referencia en cualquier otra transacción del pool, la transacción debe ser rechazada.
Para cada entrada, busque en la rama principal y en el pool de transacciones para encontrar la transacción de salida de referencia. Si la transacción de salida no se encuentra para cualquier entrada, esta será una transacción huérfana. Añadir al pool de transacciones huérfanas, si una transacción coincidente no está ya en el pool.
Para cada entrada, si la transacción de salida de referencia es una salida coinbase, debe tener por lo menos
COINBASE_MATURITY
(100) confirmaciones.
Para cada entrada, debe existir la salida de referencia y ya no puede ser gastada.
Usando las transacciones de salida de referencia para obtener los valores de entrada, compruebe que cada valor de entrada, así como la suma, están en el rango permitido de valores (menos de 21 millones de monedas, más de 0).
Rechazar si la suma de los valores de entrada es inferior a la suma de los valores de salida.
Rechazar si la tarifa de transacción sería demasiado baja para entrar en un bloque vacío.
Los scripts de desbloqueo para cada entrada se deben validar contra los scripts de bloqueo de salida correspondientes.
Estas condiciones pueden verse en detalle en las funciones AcceptToMemoryPool, CheckTransaction, y CheckInputs en el cliente de referencia bitcoin. Tenga en cuenta que las condiciones cambian con el tiempo, para hacer frente a los nuevos tipos de ataques de denegación de servicio o, a veces se relajan las normas a fin de incluir más tipos de transacciones.
Al verificar de forma independiente cada transacción, en el momento en que se recibe y antes de propagarlo, cada nodo construye un conjunto de transacciones válidas (pero sin confirmar) conocido como el pool de transacciones, pool de memoria o mempool.