Criterios de script txout (criterios scriptpubkey)

¿Cuál es el criterio para que un script txout sea aceptado en un bloque minado? ¿Hay algún criterio en absoluto? la razón por la que pregunto es que OP_RETURNse usa regularmente en los scripts txout, pero no se puede gastar:

case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}

y también he visto transacciones que empujan elementos a la pila que tienen más de MAX_SCRIPT_ELEMENT_SIZE bytes.

Supongo que un script sintácticamente incorrecto como:

05aa
(ie OP_PUSHDATA(5) <aa>)

no estaría permitido?

alguien podría señalarme el código que usan los mineros para validar si un tx se incluirá o descartará como no válido (debido a sus scripts txout). Supongo que se encuentra en main.cpp , pero me gustaría saber dónde exactamente, gracias.

obviamente, cualquiera puede extraer un bloque que está configurado de la forma que desee, pero presumiblemente hay reglas fijas sobre si se considera válido o no, por lo que otros mineros sabrán si usar su hash como su hash de encabezado anterior al extraer el próximo bloque?

Respuestas (2)

Absolutamente no se realizan comprobaciones de validez de consensoscriptPubKey en un archivo . Los nodos tienen requisitos suaves llamados IsStandard para lo que transmitirán a sus pares como una transacción (un script completamente basura o una salida OP_RETURN muy grande, por ejemplo, no pasará), pero estas no son reglas de consenso. Algunos mineros extraerán transacciones no estándar en sus bloques, pero en general, para obtener una transacción para ellos, es necesario utilizar un transporte que no sea la red P2P.

OP_RETURNes un caso especial al que se hace referencia como "probablemente indiscutible", esta es una respuesta a las personas que interfieren hashes y otros datos en las PubKeyHashsalidas como una forma de vincularlos a tiempo con la cadena de bloques. Debido a que no hay forma de saber si la salida es realmente válida o no, estas salidas deben almacenarse para siempre en el grupo UTXO. Una OP_RETURNsalida prefijada nunca se puede gastar, por lo que los nodos pueden olvidar con seguridad que alguna vez existieron.

¡gracias por la respuesta! pero seguramente si alguien construye un bloque con un script txout sintácticamente incorrecto, ¿ningún otro minero construirá sobre él? estoy buscando ese criterio, es decir, para construir sobre un bloque ya minado
He agregado un último párrafo a la op explicando un poco mejor ...
El script de salida nunca se verifica en Bitcoin, puede hacer algo que sea completamente basura ( OP_CAT OP_CAT OP_CAT) y que sea válido en un bloque. Si no hay forma de cumplir con el guión y gastarlo nuevamente, entonces el valor del BTC simplemente se queda ahí para siempre. Esta salida de transacción es similar a su ejemplo, empuja basura a la pila sin ningún motivo. webbtc.com/tx/… Puntos de bonificación si puede averiguar qué está empujando a la pila.
mmm interesante. Aunque supongo que todavía es sintácticamente correcto. por ejemplo 05aa, ¿fallaría? si no, entonces podría ser posible usar scripts txout para ataques de desbordamiento de búfer en los usuarios...
Sé que no se pueden usar en EvalScript(), esa no es mi pregunta.
No hay controles en absoluto, ni siquiera en el tamaño de las inserciones de datos. Es una matriz de bytes.
Frío. aparentemente esta transacción hace exactamente eso. Necesito echar un vistazo al hexágono sin procesar, pero una vez que lo haya confirmado, lo agregaré a su respuesta y lo marcaré como la solución. siéntete libre de llegar antes que yo :)
¡Creé una nueva respuesta, ya que los resultados resultaron ser más interesantes de lo que pensaba!

La transacción ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767de la cadena de bloques en vivo contiene muchos scripts txout sintácticamente incorrectos y es útil como demostración:

usando pybitcointools:

#!/usr/bin/env python2.7                                                        

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)

producción:

raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01

analizando cada uno de estos scripts txout:

01 = OP_PUSHDATA0(1)

esto falla porque afirma que insertará 1 byte en la pila, pero luego no proporciona bytes para insertar en la pila

0201 = OP_PUSHDATA0(2) <01>

esto falla porque afirma que insertará 2 bytes en la pila, pero solo proporciona 1 byte para insertar en la pila

4c = OP_PUSHDATA1(?)

esto falla porque es un código de operación OP_PUSHDATA1 incompleto. el 4cbyte debe ir seguido de otro byte que especifique la cantidad de bytes de datos para insertar en la pila, sin embargo, no es así.

4c0201 = OP_PUSHDATA1(2) <01>

esto falla porque afirma que insertará 2 bytes en la pila, pero solo proporciona 1 byte para insertar en la pila.

etc

es divertido que los scripts de salida en esta transacción en particular tengan cada uno un uso diferente sintácticamente incorrecto de los comandos OP_PUSHDATA. es casi como si alguien tuviera la misma pregunta que esta y quisiera probar si se implementó alguna verificación de sintaxis en scriptpubkeys. Me alegro de que hayan hecho esto porque es una forma muy concluyente de demostrar que no se realiza absolutamente ninguna verificación de sintaxis (y, por lo tanto, ninguna otra verificación) en scriptpubkeys antes de que se gasten.

Encontrará muchos scripts como este en testnet3 y un número menor en la red principal. Muchos de ellos están intentando (y de hecho lo logran en algunos casos) romper las reimplementaciones utilizando comportamientos oscuros e indocumentados.
¡sí! rompió mi reimplementación , esa es la razón por la que pregunto :) pero no veo mucho valor para validar bloques de testnet: las personas pueden poner cualquier cosa allí y no hay mucho poder de hash para incluso garantizar bloques válidos.
Nunca vas a descargar un bloque con contenidos no válidos, porque el bloque simplemente no sería válido. La cantidad de prueba de trabajo para esto es casi completamente ortogonal. Realmente no debería volver a implementar el script, la historia ha demostrado (bitcoinjs, bitcoin-ruby, btcd) que nadie tiene la capacidad de clonar el comportamiento directamente, sin importar cuántos millones de dólares se viertan en el esfuerzo. A menos que sea por diversión o experiencia, enlace libconsensusy evite perder montones de dinero. No es infalible, pero significa que no tendrá errores evitables en la ejecución del script.
gracias por el aviso pero para mi es puramente educativo. nunca sabes realmente algo hasta que puedes construirlo tú mismo desde cero.
No lo sabía libconsensus, ¡eso parece realmente útil!
Para una experiencia de aprendizaje, continúe con la reimplementación. De manera algo inesperada, así es como se han encontrado algunos errores de consenso en el pasado. La advertencia nació principalmente de personas que reimplementaron y luego dirigieron compañías de millones de dólares sin reconocer realmente el riesgo.
Frío. sí, esa es otra razón para mi re-implementación. hasta ahora siempre he llegado tarde a la fiesta - descubriendo "errores" mucho después de que bips los haya corregido
Criterios de script txout (criterios scriptpubkey)
RespuestasAquíPolítica de privacidad1y, 0v