Hasta donde yo sé, actualmente los relés de cliente "Satoshi" y la mayoría de los grupos aceptan solo transacciones estándar (transferencia o generación) . Además, la comunidad está trabajando en el tipo de transacción M-de-N . Agregar transacciones no estándar a la cadena de bloques es hoy en día bastante problemático.
Si bien actualmente habilitar scripts arbitrarios en transacciones podría ser desastroso debido a posibles errores en el código (o en el propio sistema de scripts), me pregunto si está previsto permitir transacciones arbitrarias en algún lugar en el futuro, o la mayor parte de la red siempre estará restringida a algún conjunto de plantillas de transacciones "buenas"?
La dirección de desarrollo actual (enero de 2013) es reforzar aún más las comprobaciones de IsStandard(). Por ejemplo, nos gustaría que todas las firmas se ajustaran a una codificación canónica muy estricta para hacerles la vida más difícil a los posibles atacantes.
Permitir que más códigos de operación o patrones de códigos de operación (o todos los códigos de operación/patrones) se consideren IsStandard() es ciertamente posible; antes de hacerlo, me gustaría ver un análisis exhaustivo de la posibilidad de que se produzcan travesuras utilizando el conjunto actual de códigos de operación y muchos prototipos en la red de prueba (donde la verificación IsStandard() ya permite todos los códigos de operación habilitados).
El isStandard()control se relajó a partir de 2014. Ahora puede incluir una amplia variedad de scripts en las transacciones.
Lea más aquí: ¿Qué se entiende por "estándares relajados" para los scripts de canje de P2SH en Bitcoin Core 0.10.0?
Para que el Protocolo de Bitcoin cumpla su propósito, cada Cliente debe procesar Transacciones en el mismo asunto. Para que se introduzca un nuevo tipo de Transacción y se pueda gastar, debe cumplir con las reglas actuales (por ejemplo, ser posible de ejecutar usando el Script ), o ser aceptado por todos los Clientes (idealmente). Si se implementara un nuevo tipo de Transacción sin que las personas se ajusten a ella, en el mejor de los casos la Transacción se volvería inservible, en el peor de los casos, no sería procesada por los Clientes.
Para introducir una opción de creación de "cualquier tipo de Transacciones", sería necesario crear una nueva versión del Script o algo similar. Además, este Script tendría que ser aún resistente a ataques maliciosos (por ejemplo, sin bucles o formas similares de hacer que muchos Clientes pierdan muchos recursos computacionales al verificar la validez de la Transacción).
En general, podría ser posible generalizar la creación de un amplio espectro de Transacciones con algunos cambios en el Protocolo, pero esos cambios tendrían que ser aceptados por todos. Es muy poco probable que alguna vez se pueda crear un nuevo tipo de Transacción por capricho.
OP_DUP OP_DROPal comienzo de la secuencia de comandos no invalida la transacción, pero actualmente la mayoría de los clientes no la transmitirán y la mayoría de los grupos no la agregarán al bloque extraído.
kirian
una tierra
IsStandard" registrar al cliente "predeterminado" se considera temporal o permanente.kirian