Actualización del Génesis

La actualización restauró muchos aspectos del protocolo de Bitcoin que se habían modificado en actualizaciones de software anteriores, incluida la eliminación de la mayoría de las reglas de consenso basadas en límites, reemplazándolas con configuraciones configurables para mineros que brindan a los operadores de nodos la autonomía necesaria para establecer sus propios límites, según determinen que son prácticos .

La actualización se bloqueó cuando esta transacción se extrajo a la altura del bloque 620539. La transacción utiliza un script que previamente se habría considerado que viola las reglas del protocolo y que los nodos de red que ejecutan el cliente de nodo BitcoinSV lo rechazaron.

Puede encontrar más detalles sobre los cambios realizados en la actualización aquí y la especificación completa está disponible aquí .

Reglas de consenso de bloque

Estas reglas de consenso se aplican a los bloques que se producen después de la activación de Genesis.

Tamaño de bloque: la regla de consenso que restringe el tamaño máximo de un bloque a un número específico de bytes se ha convertido en una regla de consenso configurable. El tamaño de un bloque es el tamaño en bytes de la forma serializada del bloque, incluido el encabezado del bloque y todas las transacciones confirmadas por el bloque. Se espera que los mineros alcancen el consenso sobre este valor y lo configuren manualmente.

Número de operaciones CheckSig por MB de espacio de bloque: se ha eliminado la regla de consenso que limita el número de operaciones de checkig por megabyte de espacio de bloque.

Reglas de consenso de transacciones

Estas reglas de consenso se aplican a las transacciones que se confirman en bloques después de la activación de Genesis.

Tamaño máximo de transacción: el tamaño de una transacción es el tamaño en bytes de la forma serializada de la transacción. El tamaño máximo de una transacción es de 1 GB (1,000,000,000 bytes). Se espera que esta limitación se elimine en el futuro.

Número máximo de operaciones CheckSig por transacción: se ha eliminado la regla de consenso que limita el número de operaciones CheckSig por transacción.

nLockTime y nSequence: después de la activación de Genesis, la funcionalidad del campo nLockTime de una transacción y los campos nSequence de las entradas de transacción vuelven a su propósito original. Las reglas definidas aquí solo se aplican a las transacciones que se confirman después de la activación de Genesis.

Reglas de lenguaje de script

Esta sección contiene cambios a las Reglas del lenguaje de script. Bitcoin Script es el lenguaje de programación que se usa para bloquear y desbloquear salidas de transacciones. Se puede encontrar más en: Advanced Bitcoin Scripting . Las reglas definidas aquí se aplican al bloqueo y desbloqueo de secuencias de comandos para salidas de transacciones que se crean después de la activación de Genesis. Las reglas anteriores se aplican a las salidas de transacciones creadas antes de la activación de Genesis.

OP_RETURN Funcionalidad

Se está restaurando la funcionalidad de la operación OP_RETURN. OP_RETURN provocará la terminación de la secuencia de comandos y la validez de la secuencia de comandos está determinada por el valor del elemento superior en la pila. Ver OP_RETURN .

Tipos de datos

Todos los elementos de datos en Bitcoin Script como una secuencia de bytes. Algunas operaciones interpretan sus parámetros como valores numéricos o booleanos y requieren que el ítem cumpla con los requisitos de esos tipos. Algunas operaciones producen elementos en la pila que son valores numéricos o booleanos válidos.

Gramática formal de script de Bitcoin

Se ha definido una gramática formal para Bitcoin Script. Se puede encontrar más en: Opcodes utilizados en las secuencias de comandos de Bitcoin .

Validez de la regla de consenso de guiones: los guiones de bloqueo y desbloqueo para cada entrada de una transacción deben ser gramaticalmente válidos, tal como se define en la gramática formal anterior.

PUSHDATA solo en la regla de consenso de desbloqueo de secuencias de comandos: después de la activación de Genesis, las secuencias de comandos de desbloqueo utilizadas en las entradas de transacciones solo pueden contener operaciones PUSHDATA, según lo definido por la gramática formal. A diferencia de todas las otras actualizaciones en esta sección, esta regla de consenso se activa para todas las entradas de transacciones que se confirman o se confirmarán en un bloque después de la activación de Genesis, independientemente de la altura del UTXO que se gaste. Esta regla es un subconjunto de la Regla de consenso de validez del guión definida anteriormente, pero se incluye por separado porque las condiciones de activación son diferentes.

Reemplazo de la regla de consenso

La funcionalidad proporcionada por estas reglas de consenso ahora está cubierta por la Regla de consenso de uso de memoria de pila.

Regla de consenso	Descripción
Tamaño del elemento de script	Limita el tamaño máximo de un elemento de script.
Tamaño de la pila	Limita el número combinado de elementos que se pueden colocar en la pila y en la pila alternativa.
Tamaño de script *	El tamaño máximo de la secuencia de comandos.
Número de operaciones no push por script	Limita el número de operaciones no push por script. Otras capacidades gestionan el costo de ejecución.

funcionalidad también cubierta por la Regla de consenso de tamaño máximo de transacción.

Cambios en las reglas de consenso

Regla de consenso	Descripción
Tamaño de valor numérico	Para que una secuencia de bytes represente válidamente un valor numérico, la longitud de la secuencia de bytes debe ser menor o igual a 750,000 bytes. Una secuencia de bytes que es mayor que esta es una secuencia de bytes válida pero no es un valor numérico válido.
Número de claves públicas por regla de consenso multigrado	El límite de la cantidad de claves públicas por multigrado se ha cambiado a 2 ^ 31-1 (INT32_MAX).
Uso de memoria de pila	Limita la cantidad de memoria que se puede usar en las pilas. Esta regla se evalúa contra la suma de la memoria utilizada por la pila y la memoria utilizada por el altstack.

Puesta de sol

P2SH, OP_CHECKLOCKTIMEVERIFY y OP_CHECKSEQUENCEVERIFY: la actualización de Genesis elimina la capacidad P2SH y la presencia de una plantilla de script p2sh en una salida invalidará una transición. Las operaciones de opocde vuelven a NOP, que no tienen ningún efecto.

Deshabilitar la regla de consenso de operaciones: OP_2MUL, OP_2DIV, OP_VERIF, OP_VERNOTIF. Si están presentes en un script no ejecutado, la ejecución del script puede tener éxito.

Políticas locales estándar

Las políticas son configuraciones que configuran los operadores de software. Estas configuraciones son generalmente requeridas por las implementaciones de software.

Las políticas controlan las transacciones que el software propagará a través de la red P2P o incluirá en un bloque. Sin embargo, las políticas no son Reglas de Bitcoin o Reglas de consenso y no se utilizan para determinar la validez de los bloques o las transacciones confirmadas por el bloque.

Políticas de transacciones locales estándar

Política de tamaño de transacción máximo aceptable: el tamaño de transacción máximo aceptable es una política estándar que configura las transacciones más grandes que el software propagará a través de la red P2P o incluirá en un bloque.
Tiempo de espera de evaluación de la transacción: el tiempo de espera de la evaluación de la transacción es una política estándar que define la cantidad máxima de tiempo que el software permitirá la evaluación de la transacción antes de finalizar la evaluación y rechazar la transacción. Esta configuración siempre se define con una unidad de tiempo y el valor predeterminado de 1 segundo.

Políticas de lenguaje de script local estándar

Longitud del valor numérico: la longitud de la política de valor numérico define la longitud máxima de una secuencia de bytes para que se considere un valor numérico válido. El valor predeterminado para este valor es 250,000 bytes.
Uso de la memoria de la pila: la política de uso de la memoria de la pila limita la cantidad de memoria que se puede usar en las pilas. Esta política se evalúa contra la suma de la memoria utilizada por la pila y la memoria utiliza el altstack.

Políticas de red P2P locales estándar

Propagación de transacciones no estándar: después de la activación de Genesis, la configuración predeterminada para esta política es que las transacciones no estándar se propagarán a través de la red P2P. Antes de la activación de Genesis, la configuración predeterminada para esta política era que las transacciones no estándar no se propagan a la red P2P. Todavía se aplican políticas como la Política de tamaño máximo de transacción aceptable.