Parece que las transacciones no estándar normalmente no se transmiten porque existe la preocupación de que esto pueda romper la red o dificultar las actualizaciones futuras.
Pero cualquiera puede usar estas transacciones no estándar (¡y hacer que se transmitan!) usando P2SH. Entonces, ¿de qué sirve esta restricción en scripts que no son P2SH?
Como usted dice, hay dos preocupaciones separadas aquí:
Para el caso de daño a la red, Nakamoto implementó por primera vez la verificación de transacciones no estándar antes de que existiera P2SH, por lo que no se podía eludir tan fácilmente. Esto dio a los desarrolladores tiempo para analizar mejor el lenguaje de script y solucionar problemas con los códigos de operación restantes (por ejemplo, ver casos como este en los que era posible crear transacciones cuya verificación llevaría mucho tiempo).
Sin embargo, incluso si el lenguaje de secuencias de comandos es perfectamente seguro, cada secuencia de comandos debe almacenarse en cada nodo completo hasta que se gaste como parte de la base de datos de salida de transacciones no gastadas (UTXO). Dado que las scriptPubKeys están limitadas a 10 000 bytes, esto significa que un atacante puede agregar hasta 10 KB al conjunto de UTXO por cada salida que cree, lo que podría agregar rápidamente suficientes datos para degradar el rendimiento lo suficiente como para que aumente la tasa de bloques obsoletos (bloques huérfanos) extraídos. lo que reduciría las ganancias de los mineros y los alentaría a centralizarse aún más para recuperar los ingresos perdidos.
Eso sería malo. Afortunadamente, hay una solución fácil: si usamos P2SH o segwit P2WSH, solo vemos el script completo en el punto en que se gasta la salida, cuando podemos eliminar la salida del conjunto UTXO. Esto es algo inferior con P2SH debido a que limita los scripts a 520 bytes, pero P2WSH soluciona ese problema y restaura el límite anterior de 10,000 bytes. Esa es la razón de seguridad por la que hoy en día necesitamos scripts complejos que usen P2SH.
Para el caso de actualización, hay algunos códigos de operación que no queremos que la gente use. En particular, estos son códigos de operación que podrían redefinirse en el futuro, por ejemplo, los códigos de operación OP_NOPx que se usaron para bifurcaciones blandas en el pasado (OP_NOP1 se convirtió en OP_CHECKLOCKTIMEVERIFY y OP_NOP2 se convirtió en OP_CHECKSEQUENCEVERIFY). Últimamente, Bitcoin Core 0.16.1 ha detenido la retransmisión de OP_CODESEPARATOR en non-segwit en preparación para otra posible bifurcación suave que reducirá algunos problemas persistentes con la costosa verificación.
En esos casos, las transacciones estándar prohíben las versiones scriptPubKey y redimirScript (P2SH) (y, cuando corresponda, la versión segwit P2WSH), por lo que la elusión fácil no es posible en ese caso.