Reglas de estandarización relacionadas con BIP 16 (P2SH)

Puedo leer en BIP0016 wiki la Especificación P2SH

Las transacciones que canjean estos puntos de salida de pago por secuencia de comandos solo se consideran estándar si la secuencia de comandos serializada, también conocida como redimirScript, es, en sí misma, uno de los otros tipos de transacciones estándar.

Las reglas para validar estos puntos de salida al retransmitir transacciones o considerarlas para su inclusión en un nuevo bloque son las siguientes:

La validación falla si hay otras operaciones además de las operaciones de "inserción de datos" en scriptSig. Se realiza una validación normal: se crea una pila inicial a partir de las firmas y el {script serializado}, se calcula el hash del script y la validación falla inmediatamente si no coincide con el hash en el punto de salida. {script serializado} se extrae de la pila inicial y la transacción se valida nuevamente utilizando la pila extraída y el script deserializado como scriptPubKey. Las reglas para validar estos puntos de salida al retransmitir transacciones o considerarlas para su inclusión en un nuevo bloque son las siguientes:

La validación falla si hay otras operaciones además de las operaciones de "inserción de datos" en scriptSig. Se realiza una validación normal: se crea una pila inicial a partir de las firmas y el {script serializado}, se calcula el hash del script y la validación falla inmediatamente si no coincide con el hash en el punto de salida. {script serializado} se extrae de la pila inicial y la transacción se valida nuevamente utilizando la pila extraída y el script deserializado como scriptPubKey. ...

  • OP_CHECKSIG y OP_CHECKSIGVERIFY cuentan como 1 operación de firma, se evalúen o no.
  • OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY inmediatamente precedidos por OP_1 a OP_16 se cuentan como 1 a 16 operaciones de firma, ya sea que se evalúen o no.
  • Todos los demás OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY se cuentan como 20 operaciones de firma.

Pero en el libro de Antonopoulos puedo leer

Antes de la versión 0.9.2 del cliente Bitcoin Core, Pay-to-Script-Hash estaba limitado a los tipos estándar de scripts de transacción de bitcoin, mediante la función isStandard(). Eso significa que el script de canje presentado en la transacción de gasto solo podría ser uno de los tipos estándar: P2PK, P2PKH o de naturaleza multifirma, excluyendo RETURN y P2SH en sí. A partir de la versión 0.9.2 del cliente Bitcoin Core, las transacciones P2SH pueden contener cualquier script válido, lo que hace que el estándar P2SH sea mucho más flexible y permite la experimentación con muchos tipos de transacciones novedosas y complejas.

Ahora, estoy usando 0.19.0 y puedo crear un script personalizado y confiar en él en mi entorno de registro. la pregunta es: ¿Puede el BIP0016 estar obsoleto? Y si es así, ¿dónde puedo ver qué BIP se volvió obsoleto?

Respuestas (1)

En general, los cambios en las reglas de las políticas no se especifican en los BIP. Dependen de los clientes individuales de todos modos.

BIP16 no está obsoleto, aunque su descripción de las reglas de estandarización en Bitcoin Core ya está desactualizada. Sin embargo, sus reglas de consenso (es decir, lo que es válido en un bloque, no lo que se transmitirá como transacciones individuales) no se modificaron desde que se activó en 2012; cualquier otra cosa sería una bifurcación dura.

En lo que respecta a la política en Bitcoin Core, en la versión 0.10.0 (2014), la estandarización relajada para los gastos de P2SH, permite que cualquier script use hasta 15 comprobaciones de firma. Se realizaron varios cambios posteriores a la estandarización (incluidas todas las bifurcaciones blandas afectadas por el script (CLTV, CSV, Segwit) acompañadas de la realización de los gastos correspondientes estándar), pero ninguno tan fundamental.

Las reglas de estandarización actuales (Bitcoin Core v0.19.0) para los gastos P2SH incluyen:

  • El tamaño máximo de scriptSig es de 1650 bytes, incluido el script redimido (no se aplica en la red de prueba)
  • Máximo de 15 comprobaciones de firma en el script (no se aplica en testnet)
  • No se prevén códigos de operación para futuras actualizaciones (NOP3-NOP10) [regla de desalentar nops actualizables]
  • Sin firmas codificadas sin DER ni claves públicas híbridas [regla estricta]
  • Sin firmas con valores de s en la mitad superior del rango [regla de s baja]
  • El argumento adicional que aparece en OP_CHECKMULTISIG(VERIFY) debe ser exactamente la matriz de bytes vacía (tal como lo indica OP_0) [regla nulldummy]
  • Todas las inserciones deben usar la codificación de tamaño mínimo (OP_i en lugar de inserciones directas cuando estén disponibles, no OP_PUSHDATAi cuando no sea necesario), los números enteros no pueden tener cero relleno innecesario [regla de datos mínimos]
  • La ejecución debe terminar con exactamente un elemento distinto de cero en la pila [regla de pila limpia]
  • Las operaciones de Checksig que fallan deben recibir una firma vacía [regla nullfail]
  • No se puede usar OP_CODESEPARATOR (ni siquiera en una rama no ejecutada).
  • Las firmas que se verifican no pueden aparecer en scriptPubKey (deben provenir de scriptSig) [regla de código de script const]
  • En el nivel de transacción: no hay una versión de tx superior a 2, y todo el tx no puede tener más de 400 000 unidades de peso (100 000 bytes si no hay entradas de segwit presentes).
Muchas gracias. De acuerdo con la respuesta de MCCCS, ¿no puedo replicar las reglas en regtest y testnet? No uso acceptnonstdtxnen mi conf.
Regtest es idéntico a mainnet para todo lo que se enumera aquí. Testnet es ligeramente diferente (no tiene el tamaño máximo de scriptsig o la regla de verificación de firma de 15 máximo, pero todas las demás reglas enumeradas aún se aplican).
¡Gracias de nuevo por tu tiempo! En general, regtest está cerca de mainnet, testnet es ligeramente diferente
Lo siento, actualicé mi comentario, ¿puedes verificar si puedes?
Sí, parece correcto.
Reglas de estandarización relacionadas con BIP 16 (P2SH)
RespuestasAquíPolítica de privacidad1y, 0v