Número máximo de op_codes en script

¿Hay alguna parte del protocolo de Bitcoin que establezca un límite en el número máximo de op_codes en un script?

Recientemente llegué al límite para el cliente central de bitcoin. En: https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp en la línea 276 encuentra:

   if (opcode > OP_16 && ++nOpCount > 201)
        return set_error(serror, SCRIPT_ERR_OP_COUNT);*

Interpreto esta línea como diciendo que, fuera del tipo estándar de transacciones, hay un límite para 201 operaciones además de empujar un número del 0 al 16 a la pila.

¿Está esto definido en alguna parte del protocolo o discutido en algún BIP?

Sé que hay límites para transacciones multiscript: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size y que la cantidad de firmas debe limitarse para evitar ciertos ataques, pero para operaciones ligeras (OP_ADD y similares) No puedo encontrar ninguna explicación sobre el límite y el valor exacto de 201.

PD: Encontré el error al intentar gastar el script ofensivo. Curiosamente, se me permitió enviar la transacción. Es cuando el cliente intenta verificar los datos para la próxima transacción cuando hay un problema.

Respuestas (1)

La mayoría, si no todas, las constantes como esa no se describen, documentan o discuten de otra manera. En su mayor parte, el código de Bitcoin Core es la referencia que sigue todo lo demás, en lugar del código que intenta ajustarse a cualquier tipo de estándar. Si dependiera de una documentación en particular, la red necesitaría una bifurcación dura cada vez que se encontrara un nuevo comportamiento que no cumpliera con la especificación.

Las operaciones 201 son, de hecho, el límite, y también hay un límite estricto en la cantidad de verificaciones de firmas que pueden ocurrir en un bloque. De todas las cosas en Bitcoin, el motor de secuencias de comandos es probablemente el menos documentado de todos y tiene una serie de rarezas, en parte debido a su inclusión tardía.

Es cuando el cliente intenta verificar los datos para la próxima transacción cuando hay un problema.

Puede crear todo tipo de secuencias de comandos de salida completamente inválidas porque, como descubrió, no se verifica su validez hasta que se gastan. Depende del autor de guiones no estándar comprender el sistema y no hacer que sus monedas no se puedan gastar. Si no lo entiende, pruebe estas cosas en testnet3 antes de que pierda dinero real con ellas.

Todo es prueba de testnet3. De hecho, logré enviar la transacción al mempool de un nodo de retransmisión en particular: test.webbtc.com/mempool_tx/… Usan una implementación Ruby diferente de Bitcoin. Sin embargo, parece que la mayoría de los nodos usan Bitcoin Core y la transacción permanecerá en un limbo durante algún tiempo y luego desaparecerá. Si fuera retransmitido por los clientes de Ruby, ¿la red rechazaría el bloque y crearía una bifurcación o se convertiría en parte de la cadena de bloques? Una vez que se incluye el bloque, hay menos comprobaciones...
Su transacción es rechazada por Bitcoin Core (-25), por lo que Bitcoin Ruby aceptarla sería erróneo. Su transacción es efectivamente una tontería y está tratando de gastar una salida OP_RETURN (no gastable), por lo que esto no es particularmente sorprendente. La validación de bloques no es menos estricta que la validación de transacciones, de hecho, la validación se almacena en caché y se reutiliza en ambos.
@halftimepad re test.webbtc.com/mempool_tx .... ¿Qué es eso exactamente? Conocía el relé o pushTx de la API, pero me interesa lo que quiere decir aquí. ¿Está presionando este nodo a través de REST POST o BTC Core?
Es la salida de webbtc.com/relay_tx .
Número máximo de op_codes en script
RespuestasAquíPolítica de privacidad1y, 0v