https://twitter.com/kanzure/status/972468121046061056

La idea del graftroot es que en cada contrato hay un superconjunto de personas que pueden gastar el dinero. Esta suposición no siempre es cierta, pero casi siempre lo es. Digamos que quieres bloquear estas monedas durante un año, sin ninguna condición para ello, entonces no funciona. Pero suponga que tiene... ¿recuperación pubkey? No... la recuperación pubkey es inherentemente incompatible con cualquier forma de agregación, y la agregación es muy superior. Podrías, si no hicieras la agregación.

En graftroot, si todos los participantes están de acuerdo, entonces pueden simplemente gastar. Así que pueden hacer la agregación pubkey en P. P representa el conjunto de todas las personas que tienen la autoridad para gastar las monedas, sin otras condiciones, sin hashlocks, sin timelocks, etc.

Cada vez que todos los participantes de este script están presentes en el momento de la sincronización, se utiliza Sig(P, TX) sin importar la condición. Sólo cuando esas personas quieran delegar el derecho a firmar en otra cosa. Esto es un reemplazo para las construcciones MAST. Son sólo 64 bytes, independientemente de cuántas ramas o formas haya de gastar las monedas. Son sólo 64 bytes, lo firman y dicen que se puede gastar de esta manera o lo que sea. Hay una sobrecarga logística para recordar todas esas firmas o lo que sea...

Hay un truco de agregación de lotes. Si tienes múltiples firmas (R, S)... ... sG es R más el hash de r1 ignoremos el mensaje por un segundo... algo, realmente no importa, l.. ... ¿sabes cómo funciona la validación por lotes? Agregando los valores de S. Puedo sumarlos.

Lo que ves aquí es... todos estos coeficientes g se combinan en uno solo. Ahora, qué pasa si en lugar de que alfa sea un número aleatorio real, es un hash de todas las entradas, excepto s. Así que haces una construcción tipo fiat-shamir donde digo que en lugar de ser un número aleatorio elegido por el verificador, es en realidad un número que el firmante conoce y se deriva en realidad como una salida PRNG sembrada por toda la firma excepto s. Y en realidad creo que es suficiente sembrarlo sólo con los valores R. Entonces lo que si se hace, es que en vez de obtener s1 y s2, se podría dar sólo este valor. El verificador ahora con sólo r1, r2, y s, puede validar este conjunto - donde s se define como esto.. Y el verificador sigue calculando alfa, y lo multiplica aquí y aquí, y así tiene una sola ecuación pero no necesita que le digan todos los valores de s. Así que ahora la firma es 32 bytes más pequeña que de otra manera. Este es un esquema de media agregación no interactiva para Schnorr. Sólo agrega los valores S pero no los valores r. Pero significa que la raíz del injerto sólo tiene 32 bytes extra y no 64 bytes.

Las dos firmas aquí tienen su propio valor R, pero sólo hay una única s globalmente para toda la transacción. La clave pública está en las salidas. Graftroot es una firma que utiliza esa clave pública y un script como mensaje, el propio script, y una entrada a los scripts. El input tendrá la pubkey sin el hash--- no importa en realidad.

Esta firma es realmente sólo un valor R, y hay un valor S global de todas las transacciones... porque esta agregación no es interactiva. Puedo tomar dos firmas válidas y sin tener su clave privada, combinarlas, porque el alfa sólo depende de los datos públicos, es un valor generado determinísticamente recuerde, por lo que puede ser hecho por cualquiera.

Haciendo esto al mismo tiempo que la agregación de entrada cruzada Schnorr cosas - todos ellos se combinan muy bien. Hay una sinergia entre ellos. Esto le da arbitrariamente muchas ramas de script, por sólo 32 bytes.

Sí, estoy explicando graftroot.

Quiero demostrar que graftroot es seguro. Y taproot y Schnorr al mismo tiempo. No puedes añadir más cosas para agregar en un soft-fork, así que deberías hacerlo todo de una vez. El problema es que tendrás una transacción con firmas y luego tienes la salida de graftroot sin script, y no tendrá una clave pública dentro de su script, esa firma no puede ser agregada con todas las demás, si ... está en un soft-fork.. porque, no hay, firma agregada con todas ellas, y no ser capaz de validarla porque no ve esa clave pública. Tendrías dos firmas agregadas en lugar de una. El beneficio es mucho menor si necesitas tener una nueva firma agregada para cada versión de soft-fork. Así que quiero que entren todos a la vez. Quiero árboles de merkle.

Primero hago mi script. Luego hago una firma aleatoria... un hash de un... y luego de ese par de script de firma, calculo la pubkey. Y luego establezco esa pubkey. Puedo mostrarte que la-- la preimagen para esta firma, así que esto es básicamente probarte que.... no hay... que pueda ser posible. podrías hacer más de una.

....

Dados dos mensajes y una sola firma fija, encuéntrame una clave pública... Dados dos mensajes, encuéntrame una clave pública que firme ambos, a no ser que conozcas la... Creo que tengo una prueba informal de que..

...

Probablemente nunca deberías enviar dinero a personas que no esperan recibirlo. Pero la gente probablemente seguirá haciéndolo de todos modos.

Siempre hay una firma global en la transacción. Hay una firma en alguna parte de la transacción. Todo se agrega a la firma. ...

Un graftroot donde se puede enviar de forma no interactiva al multisig de alguien... a algún script arbitrario para el multisig con claves en él. Podrías hacer, pero haces el tihng directo. Quiero un script multisig de 2 de 3 y quiero hacerlo sin pedirle a la gente que firme nada ni hacer ningún injerto. No se puede. ¿Estás seguro? Puedes, con el recovery tricky, siempre que haya al menos un único script. Puede que no funcione aunque.... esta firma no firma el txid, sólo firma los scripts. Funciona. Pero sólo mientras haya un solo... y si estás haciendo eso, ¿por qué no estás usando taproot? Es más barato. La única razón por la que lo estás haciendo es porque quieres graduarte de taproot a graftroot... por razones de fungibilidad tú.. ¿No sería genial fusionarlo todo? Digamos que yo tengo una clave pública, y tengo un script, y arreglado por adelantado, y tú no puedes. Usted quiere hacer graftroot. Si P es fijo, entonces usted no puede. Pero si sólo quieres enviar a un script, entonces podrías usar graftroot. Quieres enviar de forma no interactiva a un script... queremos enviar de forma no interactiva a un script que no tiene relación con esta pubkey con la que no tiene relación, pero eso es imposible. Dices que es inusual que tengas una clave pública y un script por adelantado. Si no tienes no-interactividad, entonces graftroot hace todo. 2 de 3 multisig-- 3 posibles scripts ahora. Eso no es tan eficiente como tener 3 scripts.. entonces de nuevo, 2-de-3... En graftroot, deberías estar enviando a una colección de pubkeys, y ellos pueden decidir delegar a scripts particulares. Mientras tengas esta colección de llaves públicas, es completamente no interactivo.

...

Taproot: P = c + H(c || script) G

Graftroot: sig_p(script)

Una salida es un punto p. c es algún otro punto. Hay algún otro punto, y su clave privada puede no existir.

El gasto directo es sig_p(tx).

Taproot gastando...

La scriptpubkey se convierte en una pubkey real, esa es la discusión sobre si debe ser una pubkey o una pubkeyhash. Una vez que tenemos ordenadores cuánticos....

La salida es una clave pública y un número de versión. Hay tres maneras diferentes de gastarlo- o bien firmar con la clave y hay una transacción que es la situación más común. Cualquier clave única. Es solo una firma... puedes querer usar musig para construir la clave pública pero eso es solo una de las posibilidades, y depende de la billetera. Has dado autorización a esta clave pública para gastar esta salida.Hay una firma con esa clave que se está gastando. Sin embargo, a veces no es una clave pública. Sí. Llamarla clave pública es probablemente..... es una clave pública en el sentido de que es una scriptpubkey, alguien con un ordenador cuántico puede gastarla.

Taproot es... después del hecho, revelamos que esta clave pública que estaba en la salida no es en realidad una clave pública directa, pero era de hecho una clave pública que se derivó de otro punto de curva elíptica y un script. Esta función, que toma C y S, es la construcción de pago por contrato. Puedes verlo como una función hash de puntos y guiones a puntos. Dado un valor p, no hay manera de dar otro C y S que no sea el C y S con el que se construyó. Es un compromiso vinculante, lo que significa que esta clave pública, que estoy revelando al mundo que este pubkey fue creado con el conocimiento de que la secuencia de comandos estaba en él. Taproot es la idea de que si haces eso, entonces el script se permite como gastarlo también. Otra forma de verlo es que taproot está combinando el pay-to-pubkey y el pay-to-scripthash en una sola clave pública con la ventaja de que, a menos que estés usando la versión del script, no estás revelando que había un script. Es una ganancia tanto de eficiencia como de fungibilidad.

In(s) son las entradas a S. Si estás gastando a través de script, necesitas resolver el script, el script puede implicar checksigs, en cuyo caso tienes firmas.

G es el generador regular. C es... hay dos posibilidades aquí. Estas son sólo las reglas permanentes. En términos de cómo construirlo, hay dos maneras. Una es, tengo una clave pública que se permite gastar, y tengo un scrpit que se permite gastar, y C es esa clave pública. P es la clave pública combinada que encapsula ambas políticas. Otra posibilidad es cuando .... C es alguna función hash que mapea dos puntos directamente. Si sólo tengo una secuencia de comandos, y quiero hacer que se vea como una salida de taproot, de hecho no quiero revelar--- al gastarlo, siempre voy a revelar una secuencia de comandos, pero no voy a revelar que no hay ningún punto para empezar, puedes generar C como un punto aleatorio en la curva, puedes probar a la gente que generaste C de una manera particular para que no puedas gastarlo excepto a través de una secuencia de comandos particular. Dices, tomo una cadena aleatoria, hago un hash, uso ese hash como la coordenada x para C, y al revelar la preimagen de ese hash, sabes que nadie conoce el logaritmo discreto. La sobrecarga es baja.

La tercera forma es la raíz de injerto. Permítanme dar un paso atrás. La razón por la que taproot parece atractiva es porque en general se puede Creo que es una suposición razonable, pero la gente que sabe más acerca de los contratos de nivel superior, siéntase libre de intervenir. Creo que hay un caso razonable para hacer que en la mayoría de las construcciones de contratos inteligentes generalmente habrá un grupo de personas que se permiten conjuntamente gastar las monedas incondicionalmente. Cuando se ponen de acuerdo para gastarlas, está bien. Generalmente, como mínimo, esto puede ser todo el mundo involucrado en el contrato. Y en el peor de los casos, esto no se utiliza nunca. Existe un grupo de personas que están autorizadas a firmar las cosas. Sabiendo que hay protocolos de configuración de claves que hacen k-de-n o incluso construcciones más complejas, hay una clave única que también podría ser incorporada ahí, podríamos hacer un multisig 2-de-3 ahí, como una clave única ahí. Taproot es ventajoso siempre que podamos decir, bueno, en el caso normal, todo el mundo estará de acuerdo, y firmamos, y en realidad no necesitamos revelar el script que se utilizó. Taproot fusiona ese caso con un equivalente estándar de p2pk de manera que ya no se pueden distinguir estos dos casos.

Un paso adicional es que si ya tenemos esta suposición de que generalmente hay un grupo de personas que pueden gastar juntos, entonces bien, ¿qué pasa si los hacemos responsables de decidir qué otros guiones pueden ser delegados? Esto es efectivamente un nivel de delegación en el que dices, sólo voy a... tenemos este grupo de personas que están involucradas, ellos firman esto, y "bueno después de que este tiempo ha transcurrido, entonces puedes firmar también" te dan una firma en ese guión y ahora puedes gastar revelando esa firma más el guión y más las entradas a ese guión. Lo más interesante aquí es que puede haber un número arbitrario de estos injertos.

petertodd dice que ha escrito esto antes, lo de DEX. Hablamos de la delegación en este contexto. Sí, lo recuerdo. Pero graftroot tiene una cosa de media delegación, que es una optimización.

Esto es supongo que uno de los inconvenientes... usted puede saber que no hay manera de gastar fuera de su conocimiento existe, si usted es uno de los participantes en la clave y se niega a firmar algo que no te involucra ya, pero en general no se puede demostrar fuera de línea a alguien que toda la política es "esto", porque existe como cosas turbias.

¿Cómo se haría esto con multisig? Hay... si usted está bien con el uso de un protocolo de configuración de claves. La suposición aquí es que tienes un grupo de personas que se conocen, tienen conexiones autenticadas encriptadas entre sí, y quieren configurar una clave multisig. Pueden ejecutar un protocolo para decidir cuál será P. Hay protocolos por los que se puede codificar cualquier esquema de multifirma como una sola clave, y no necesita musig, pero podría. ¿Puedes delegar cada una de esas claves de alguna manera? Esto no involucraría a Graftroot en absoluto. Es sólo una clave. Sí se puede hacer la delegación con graftroot. Cualquiera que esté autorizado a gastar el dinero directamente, puede autorizar a otra persona, puede autorizar un script. Puedes hacer rotación, un nuevo 2 de 3 con la vieja llave rotada tal vez por ejemplo. Alguien podría dar su clave privada a otra persona, que es otra forma de delegación, que es definitivamente compatible con graftroot.

Podría haber un byte antes del script para decir que es un taproot/graftroot. Digamos que lo hace como un nuevo tipo de dirección segwit, podría tener un nuevo byte de versión.

Como esto interactúa con la agregación de firmas es algo donde estas dos propuestas se vuelven extra interesantes. Esta firma en las funciones Input() aquí, puede ser agregada interactivamente en una sola firma. En lugar de tener realmente una firma allí y allí y allí, sólo en algún lugar de la transacción hay "la" firma para la transacción o posiblemente múltiples. En el caso más general, todas ellas pueden combinarse en una sola firma. Lo que significa que el coste marginal de un gasto directo adicional es exactamente cero bytes. El testigo de la secuencia de comandos para tal entrada estaría simplemente vacío, porque está totalmente encapsulado en la firma agregada para la transacción. No es cero bytes, es cero bytes más la entrada de la transacción (txid).

Lo que no se puede agregar de forma interactiva, es la de graftroot aquí, se podría hacer pero sería estúpido. Implica que los firmantes están en línea, pueden hacer un gasto directo en primer lugar. El único caso en el que se quiere utilizar el graftroot, es realmente cuando P, quienquiera que se refiera, no está en línea, pero tú sí y con las personas involucradas en S en línea. Quizá tengan una orden judicial que les impida gastar la transacción... quizá el mundo ya sepa que es un graftroot, así que quizá tú también quieras gastarlo a través de graftroot. Sólo tiene sentido cuando P no está en línea, y como resultado no puede ser agregado interactivamente... Sin embargo, puede ser medio agregada de forma no interactiva. Se trata de una construcción en la que si tenemos múltiples firmas de la forma (R, S) y de la forma (R, S) y así sucesivamente... ... esto es sólo una conversión general, y esto se puede hacer de forma no interactiva, lo que significa, que diferentes grupos de personas pueden producir diferentes pares R-S y cualquiera puede combinarlos en múltiples valores R pero sólo un único valor S. El coste marginal de esta cosa es ahora de 32 bytes, en la construcción del injerto. Bueno, tal vez 32,125 bytes debido al bit extra.

Un beneficio adicional aquí es que después de que la media agregación está hecha, nadie puede sacar el valor S original. Si alguien envía más tarde dinero a la misma dirección original de graftroot, no puede encontrar una delegación de una transacción antigua y sacarla. Pero si estuvieran involucrados en esa transacción, que es el único caso en el que se beneficiarían de hacerlo, entonces ya tendrían la firma de todos modos. Pero es bueno ver que esto está unido y que no se puede descomponer en los valores originales de R y S.

Tal vez en graftroot se debería añadir algo para evitar las repeticiones. Meshcollider sugirió algo donde, esta cosa podría firmar no solo el script sino que también podría firmar el txid y el índice de salida del utxo que se está gastando lo cual tiene la desventaja de que solo podrías crear estas firmas después de que la transacción haya ocurrido, pero lo hace completamente no reproducible, lo que hace que la reutilización de la dirección sea segura, no estoy seguro si esto es una propiedad deseable pero ahí está.

Si la clave graftroot se utiliza más de una vez, incluso si la delegación no ha venido con ella, si tienes conocimiento de estas firmas, puedes hacer replay de la firma graftroot. Pero un tercero no puede recuperarla con .... Si conocieras todos los valores de R y S, podrías reutilizarla. Si eres una de las personas en P, y lo construyes, entonces probablemente lo sabes de todos modos.

Desventajas de graftroot... así, taproot parece como un-- en el caso, tengo una clave pública que puede gastar y un script que puede gastar, esto es una mejora sobre lo que ya tenemos. Esto puede no ser obvio-- siempre que estamos hablando de múltiples firmas en una transacción o un bloque, un objetivo es la validación por lotes donde podemos validar múltiples grupos de firmas a la vez, incluso cuando no están agregadas ya... La ecuación del taproot que tenemos que validar en el momento en que se gasta, puede ser validada por lotes junto con las firmas aunque no sea una firma, implica una multiplicación de curva elíptica relativamente cara. Por otra parte, se podría argumentar que es un negativo neto debido al coste de esta multiplicación, que es peor que un simple hash. Con la validación por lotes, esto es mucho mejor. Estamos hablando de la validación por lotes de múltiples firmas.

La agregación de claves que es, vamos a combinar múltiples claves juntas de tal manera que sólo cuando todas las claves privadas relevantes están en línea, podrían producir juntas una firma para esa clave.

La agregación de firmas consiste en que varias personas van a firmar su propio mensaje, pero nosotros combinaremos todas las firmas en una sola. Una sola firma, múltiples claves, múltiples mensajes.

La validación por lotes tiene múltiples pares de firmas (mensaje, firma, clave) y sólo como mejora computacional, estoy validando todas a la vez, y no me importa cuál falla, sólo me importa si son todas válidas o alguna de ellas es inválida. La validación por lotes es muchas veces más rápida que la validación de firmas individuales. Este es un factor no trivial. No es sólo "sumar todos los hashes", al menos para hacerlo de forma segura. Hay que multiplicar cada uno por un número aleatorio diferente, y luego sumarlos.

Una clara desventaja de graftroot es que requiere un protocolo interactivo. La multiplicación por G es costosa, salvo la validación por lotes. Por ejemplo, no se puede hacer eso de que, ahora mismo, tres personas tienen cada una su cadena de claves públicas extendida bip32 y yo voy a hacer automáticamente un 2 de 3 de las claves correspondientes a lo largo de ellas, y creo que hay un bip que propone esto y hay software por ahí que funciona así... En los intercambios, no creo que la gente ha hecho esto en la producción, que tienen 2-de-3, pero se degrada después de una cierta cantidad de tiempo con las claves de copia de seguridad o para la recuperación de claves. Hacer este tipo de conversión mecánica de conjuntos de claves y convertirlo en un script, no se puede hacer con graftroot. Cada instancia requiere interactuar con el grupo involucrado. Es usar la delegación para algo para lo que no se usaría la delegación en primer lugar. Si quieres MAST con un millón de scripts diferentes, supongo. Podrías hacer sigs de árbol dentro del .... Pero esto es O(1). Usted no quiere un árbol. Esto tiene propiedades mucho mejores en graftroot, si puedes hacerlo. Es injusto decir que sólo haces esto cuando quieres delegar - es más bien, estás aprovechando la delegación para implementar varias políticas de gasto.

La delegación es algo de lo que se ha hablado durante un tiempo, y ciertamente tiene casos de uso... pero graftroot lo convierte en una forma real de cómo podemos tratar con políticas de gasto complejas. Lo cambia de un contrato inteligente marginal de participantes fuera de línea, a que podamos hacer multifirma masivamente escalable con hashlocks y timelocks involucrados. 32 bytes. ¿Contra 120 bytes? o 300 bytes? Eso es enorme, maaku.

La privacidad es buena porque puedes hacer que todos usen lo mismo. No revelas nada sobre la profundidad del árbol o lo que sea. En cuanto a la escalabilidad, tienes mucha interactividad aquí, así que si tienes muchos firmantes... Si usted es como, hey quiero hacer un millón de secuencias de comandos aquí, y tengo un montón de participantes, entonces esto es un montón de firma y un montón de firma interactiva y un montón de almacenamiento para todas las secuencias de comandos. Necesitas almacenarlo una vez que estás participando. Puedes ser capaz de reconstruir los scripts, las firmas no puedes reconstruirlas.

En términos de despliegue de taproot y graftroot, estos podrían coexistir ya que no interfieren entre sí. Creo que debería haber un tipo de salida que pudiera ser gastado por cualquiera de estos tres mecanismos.

Una optimización menor- cuando se hablaba de un taproot de un punto nada en la manga.. La coordenada x es una clave pública válida pero nadie conoce el logaritmo discreto a. No querrías usar esto por razones de fungibilidad, porque estás revelando el hecho de que no hay clave. Así que deberías usar p2sh en ese caso, porque lo vas a revelar de todos modos.

Podrías hacer un taproot... y luego con ese taproot P, firmar una firma adecuada, para que puedas tener una clave pública por ahí.. pero las tres cosas podrían ser posibles. No sé por qué. Pero podrías hacerlo. Hace que te preguntes: ¿deberías permitir un gasto de taproot contra un graftroot delegado? Podrías imaginar un lenguaje de scripting con una rama IF, y sería "if pubkey else another pubkey" y la codificación de las ramas sería esa. No utilizarías un lenguaje de scripting... simplemente compondrías estos tipos de forma independiente. Pero supongamos que quieres especificar alguna cosa condicional, donde quieres delegar en un conjunto de claves controladas por otra cosa. No será necesariamente sencillo.

¿Qué pasa con la recursividad del graftroot? Esto termina siendo un árbol de sintaxis abstracta merkleized (MAST). O una clave pública, o un tiempo de bloqueo relativo. Esto es esencialmente funciones hash. El graftroot recursivo sería realmente lento para los MAST. En cada recursión, se requiere una operación de curva elíptica. Casi siempre, tendrás un solo nivel. Una construcción de MAST construida a partir de hashes será más eficiente que usar graftroot como un nodo en un árbol, debido a la operación de curva elíptica en cada nivel en el caso del árbol graftroot. Incluso con el taproot recursivo, estás haciendo cantidades recursivas de operaciones de curva elíptica.

Puedes convertir un taproot en un graftroot. Es similar a PGP. Es literalmente el diseño de PGP para hacer esto. Tienes una clave de identidad, y esta firma el permiso para usar algo bajo tu nombre. Esta es la razón por la que Petertodd hizo cosas DEX.

Digamos que tienes un soft-fork que añade la agregación de la firma. Y luego haces un soft-fork para graftroot. No puedes agregar a través de los dos tipos... no puedes hacerlo. Bueno, se puede, pero no lo hagamos. Tenemos que tener en cuenta que esto es difícil. Esto puede ser más difícil de lo que parece. No agregues a través de diferentes versiones, pero ¿cómo lo haces? ¿Cómo te aseguras de no hacerlo accidentalmente? Tu conjunto de UTXO con bytes de versión diciendo versión 1, versión 2. Espero que en el futuro no estemos restringidos a 16 soft-forks. Aquí está la cosa, ha habido esta idea en el pasado.... aquí es lo que estaba esperando proponer, hasta que se señaló que esto no funcionaría - el byte de versión que va en el primer byte para el testigo, y la versión para la salida es sólo el hash? Eso fue lo que dijiste hace unos años. No, el pensamiento cambia, lleva tiempo. Bien, de acuerdo. Entonces, lo que podrías hacer es, digamos, que tenemos todo este rango de opcodes sin usar. Introducimos el tipo de salida testigo v1. Y es todas estas cosas, agregación de firmas, checksig, checkmultisig que se integra con él, tparoot, graftroot, y todas las cosas. Hacemos todas esas cosas, y agg sig, graftroot, y taproot, y seleccionamos este rango en la lista de opcodes del script y todos esos opcodes se rehacen para ser opcodes "return true". Y ahora, por lo tanto, hasta ahora, no probloem, no hay ninguna razón por la que no podía hacer esto. Pero ahora quieres hacer un segundo soft-fork que reclasifique... los soft-forks en uno de esos opcodes como "cualquier cosa", alguna cosa aburrida, podría ser un "return true" a "return false". Estúpido soft-fork, pero podrías hacerlo. No, en realidad, tiene que convertirse en un condicional. No es... podría fallar, pero necesita convertirse en un "comprueba si hay N transacciones en la transacción". Tal vez empujar cosas en la pila. Está causando un problema con estas otras cosas.. si es "op true" a "op return false" todavía funcionaría como un soft-fork pero por qué lo harías en primer lugar. No es un problema, pero es una cosa tonta para hacer allí. Pero de todos modos, digamos que convertimos uno de esos "op reutnr true" en "op merkle algo".. cualquier checksig, puedes tener un script con un checksig después de este merkleverify. Ese checksig no se puede agregar con los anteriores. Eso es de esperar. Donde se indica el... vas a tener nodos que no saben de esto.... Mi idea original era que, no tendríamos una sola firma para toda la transacción, habría un número de ellas, tendrían un número de cubo, y cada firma que se hace dice a qué cubo pertenece, y que el básicamente, cada nuevo soft-fork que potencialmente cambia la ejecución introduce un nuevo rango de cubos. Como un nuevo número. Una vez que estás en una ruta de ejecución que depende de este particular soft-fork, estás implícitamente incluso en ese grupo, tienes que hacerlo implícito. Así que primero los cubos 0-16, y luego los cubos 16-32, y todavía se llamaría cubos 0-16, pero es sólo en un régimen diferente para el script, para cada régimen de soft-fork. No es un problema que no se pueda agregar a través de soft-forks (se podría hacer, pero no se debería, aunque sé cómo hacerlo funcionar). Sin embargo, todavía hay que evitar que alguien cree algo como una implementación ingenua haría la agregación mal. Su implementación podría incluso ser inconsistente consigo misma.

Las salidas de los testigos son de hasta 40 bytes, podemos tratar los últimos 8 bytes como más número de versión. Esa es la razón por la que está ahí. Podrías simplemente decir, los v1 se agregan aquí, los v2 se agregan allí, los v3 se agregan allí... Y entonces no necesitamos hacer nada de este baño de sangre de ejecución condicional.

¿Cuántas horquillas suaves estás buscando? Si juntas la agregación de firmas con taproot y graftroot, entonces podría tomar más tiempo. Para cuando lleguemos a la v16, estaremos muertos. Los soft-forks podrían ser cada vez más difíciles de desplegar.