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

Sipa, ¿puedes firmar y verificar firmas ECDSA a mano? No. Sobre GF(43), tal vez. Los inversos podrían tomar un poco de tiempo para computar. Sobre GF(2).

Creo que lo primero de lo que deberíamos hablar es de algunas definiciones. Me gustaría empezar distinguiendo entre tres cosas: Agregación de claves, agregación de firmas y validación de lotes. Más adelante, la multifirma.

Hay tres problemas diferentes. La agregación de claves es cuando hay un número de personas con su propia clave, que quieren producir una clave combinada que sólo puede firmar cuando se reúnen. Esto es lo que se quiere hacer para el multisig, en realidad. Digamos que 2 de 2 multisig juntos, el mundo no necesita saber que somos 2 de personas, por lo que esta es una dirección combinada y el dinero sólo puede ser gastado cuando ambos firman. Esto se hace en el momento de la configuración, antes de realizar cualquier firma. Cuando se establece la clave pública, se han hecho algunas operaciones para hacer esto. Esta es una nueva clave, antes de que ocurra nada.

Agregación de firmas es el problema en el que hay varias personas que van a crear firmas juntas, pero al final sólo quieres una firma. En este caso, hay múltiples firmas involucradas y sólo se produce una única firma combinada. El verificador sigue conociendo todas las claves públicas. El resultado es que en este caso tienes una firma, una clave pública y un mensaje que va al verificador. Pero en el caso de agregación de firmas, es una firma, pubkeys, y un mensaje. Necesitas todas las pubkeys. Esto se hace en el momento de la firma. Los firmantes de este mensaje no necesitan hacer nada por adelantado. Todos tienen su clave, no se comunican por adelantado, crean una firma juntos, pueden dársela a cualquiera, con la lista de pubkeys, y luego pueden verificarla.

La validación por lotes es algo que se hace en el momento de la verificación, en la que los firmantes no participan en absoluto y en la que se tienen múltiples tuplas de (mensaje, clave pública, ... firma). Algunas de ellas pueden ser potencialmente firmas agregadas. Simplemente tienes múltiples cosas que vas a verificar que son posiblemente claves agregadas y vas a verificarlas todas al mismo tiempo. Sólo sabes si todas son válidas o no. No sabes cuál de ellas está causando un fallo. Pero esto es lo que nos importa durante la validación del bloque. Si falla, puede volver a una validación escalar. La velocidad de la validación por lotes se aplica incluso si no todas son firmas agregadas. Así que todavía hay una mejora de rendimiento allí.

Gran parte de este trabajo comenzó con el análisis de la agregación de claves. Había una buena noción de que en Firmas Schnorr puedes sumar firmas y tienes una firma válida para la suma de las pubkeys. Pero luego vimos la agregación de firmas que es el caso de uso de querer tener una firma en una transacción. El caso de uso de la agregación de claves es la multisig, la agregación de firmas es para reducir las firmas en una transacción a una o a unas pocas, y el caso de uso de la validación por lotes es simplemente la mejora del rendimiento. ¿De dónde vienen las ventajas y beneficios? Me lo guardo para dentro de unos momentos.

Se puede hacer una validación por lotes en un valor agregado no interactivo. Sí. En un momento. Hay algunas cosas más que puedes hacer. Creo que primero tengo que explicar un poco las fórmulas allí.

El problema de unir todas las firmas de una transacción en una sola, pensamos que podríamos utilizar el esquema de agregación de claves con la esperanza de hacer la agregación de firmas, ... hay un problema de anulación. La agregación ingenua de claves es donde sumas las claves, con las firmas Schnorr simplemente sumas tus firmas para firmar, lo cual es genial, pero hay un ataque donde si haces ese protocolo entonces el ataque es que la pubkey es la negación de su pubkey más algún otro valor, y entonces cuando lo sumas su pubkey se cancela y puedes firmar por él solo. Si usas esto en la validación de la firma, entonces sería vulnerable. El ataque consiste en que ves que Greg tiene una salida en la red, conoces su pubkey (Pgreg), creas una nueva salida tú mismo que envía a (Pyours - Pgreg), y luego creas una transacción que gasta ambos juntos, y como (Pyours - Pgreg) + Pgreg suma a Pyours, del cual tienes la clave privada, y puedes firmar diciendo que soy ambas personas.

Bueno, ¿podemos encontrar una solución que resuelva el problema de la cancelación? Bueno, se nos ocurrió un esquema, luego lo rompimos, se nos ocurrió un esquema mejor y luego una prueba, luego lo escribimos en un documento, lo presentamos a FC17 y luego dijeron que este problema está resuelto y que su prueba no es lo suficientemente fuerte. Nos dieron algunos comentarios y nos dieron un documento para que lo miráramos, Multifirmas de Bellare-Neven, que es una variante de las firmas Schnorr pero que soporta de forma nativa la agregación de firmas. No hace agregación de claves, y no se puede utilizar para la agregación de claves porque sólo funciona en el caso de que el verificador conozca todas las pubkeys. El esquema que se nos ocurrió es muy similar. No tenemos una prueba de seguridad, y ellos sí.

Probablemente sea mejor no hacer las dos cosas a la vez. Son problemas diferentes. La agregación de claves no es difícil. Los cofirmantes necesitan confiar entre sí. Pero no puedes hacer eso con ECDSA... puedes agregar las claves, pero no puedes firmar sin terribles. Hay papeles. Usan criptografía rara y seis rondas de interacción y locuras.

Si se produce un ataque en el que se pretende hacer una agregación de firmas, una de las claves se hizo utilizando la agregación de claves... Sí, eso es un riesgo. Pero el riesgo sólo afecta a las personas que participaron en la agregación de claves. Y eso no es una preocupación porque - si Bryan y yo queremos hacer una multisig juntos, pues tenemos que llegar a una dirección que nos guste a los dos. Si puedo afirmar al azar que X es Bryan y mi clave, eso ya es un problema porque sólo me está escuchando. Nos importa una configuración en la que pueda convencer a Bryan de que X es una clave para ambos.

¿Afecta lo de la multisig al formato de la firma? La agregación de claves no lo cambia. Sólo resuelve pero es compatible con. Bellare-Neven se reduce a Schnorr para una sola clave y si haces alguna de las agregaciones de claves, puedes usar esas claves en Bellare-Neven aunque sea agregada. Digamos que hay una multisig y Bryan tiene la clave y yo tengo su clave y mi propia clave, y él ha verificado mi clave también, entonces afirmamos que P es la suma de nuestras claves. Le decimos a la gente que P es nuestra clave, la gente paga a P. Y la gente también ha pagado a Greg que es una sola clave. Así que ahora hay Pbryan + Psipa = Pbs. Y Pgre. Podemos crear un multisig de Bellare-Neven que es verificable... Alguien paga a Pbs y alguien ha pagado a Pgreg y podemos construir conjuntamente una única transacción que gaste Pgreg y la moneda unida con todo lo que quieras. Los tres podemos colaborar para construir esta transacción, pero lo único que ve el mundo es (sig, Pbs, Pgreg, M) donde M es el mensaje. Y Greg/Pieter no podría averiguar un valor para engañar a Bryan, porque la firma no sería válida debido a las propiedades de Bellare-Neven multisig. Puedes firmar un mensaje para demostrar que conoces el registro discreto. El problema de la cancelación podría existir... Pieter podría convencer a Bryan de no seguir el protocolo correcto, y hacer un ataque de cancelación. El esquema anterior resolvería esto, pero no sabemos si es tan seguro como el esquema Bellare-Neven. Los participantes pueden firmar con su única clave que quieren agregar, para demostrar que no tienen trucos de cancelación, pero es interactivo. Hay una técnica de delineación, pero sin una buena prueba de seguridad. Se puede pre-firmar un mensaje, si se publica la firma en algún lugar, por lo que no es necesario que sea interactivo.

La agregación de claves es que entre los cosignatarios usted mismo firma su clave pública, lo que demuestra que tiene la clave privada. Este es el comportamiento de la cartera para multisig. Es compatible con las cosas de la firma agregada, que son reglas de la red.

Andytoshi ha implementado Bellare-Neven multisig. Está escrito, probado, evaluado y con optimizaciones de rendimiento en curso, pero aún no está revisado.

Digamos que x es la clave privada, P es xG así que P es la clave pública. Entonces tienes k que es el nonce. Y luego tienes R que es el nonce por G. Y m es el mensaje. La función Hash es H. Así que la fórmula Schnorr es que tienes una firma (R, s) que es (k * G, k - H(R || P || M) * x). Si no incluyes la clave pública en ese hash, no es una prueba de conocimiento. En bitcoin, la clave pública siempre está en el mensaje.

En Bellare-Neven multisig, todavía hay (R, s) pero ahora es igual a (k * G, k - H(R || P | C || m) * x1 - H(R | P2 || C) * x2), donde C = H(x1*G, x2*G). C es sólo un hash de todas estas personas están participando, y que va en la función hash también, usted tiene un término para cada ... R se computa con múltiples firmantes. Así que la forma en que esto funciona es que cada participante tiene su propio nonce k1 y k2, y luego un correspondiente R1=k1*G y R2=k2*G. Así que tienes una ronda de interacción donde cada uno publica su propio valor R, como R1, R2, R3, sumas estos valores R, y esa suma va en la llamada de la función hash. Así que ahora todo el mundo puede construir este término, publicas todos esos términos, así que tienes a alguien que crea k1 - H(R || P1 || C || m)*x1, alguien crea k2 - H(R || P2 || C || m), y así sucesivamente, sumas estos, k1 + k2 + k3 se convierte en k, y esos términos son los que entran en la firma. Este esquema evita los ataques de cancelación porque el hash de cada clave pública se multiplica por es diferente para cada uno. El hash cambia según el contenido de las pubkeys, así que no puedes elegir una pubkey para cancelar la de otra persona, porque si lo haces, cambia el hash. Si intentas modificar tu propia clave para anular las de otra persona, entonces cambias la C, y este es un argumento intuitivo de por qué es imposible. La prueba real está en el documento.

Lo que esto reduciría a una propuesta de Bellare-Neven para Bitcoin, si queremos la agregación de firmas... así que queremos una cosa en la que sólo hay una firma por transacción, añadimos un nuevo opcode que es similar a OP_CHECKSIG pero siempre tiene éxito. En lugar de hacer realmente la verificación, empuja un par de claves públicas de mensajes a un contexto de validación por transacción. Después de que todas las comprobaciones del script para las transacciones estén hechas, se verifica todo de una vez. Esto es para la validación de firmas, no para la validación por lotes. Hay un operador checksig, lo llamas muchas veces, le pasas un hash de mensaje y una pubkey, y el hash de mensaje está implícito. Cada checksig calcularía implícitamente un hash de mensaje, una clave pública, y la firma que detecta como entrada. Ya no toma la firma como entrada, sino que toma una clave pública de la pila y computa un hash de mensaje para firmar, y simplemente los introduce en un contexto de validación por transacción. ¿Los mensajes son diferentes para cada firmante? Sí. Así que lo que realmente se firma es el hash de todos esos hashes de firma junto con todas las pubkeys y tienes un lugar designado en la transacción como, por ejemplo, para el primer checksig que pasa una firma o aquí hay un lugar particular bien definido, o un testigo a nivel de transacción (pero eso es incompatible y gratuito). ¿No se pueden mezclar varios agregados? En una de las cosas, podría haber un contador por lo que podría hacer múltiples contextos y, a continuación, usted dice que el contexto que está trabajando, no estoy seguro de que es necesario, creo que hay ya sea todo lo que utiliza ...

El almacenamiento en caché de los scripts simplemente... los scripts ya no contienen un checksig real, sino que los verificas como si fueran... automáticamente tienen éxito. El script de Bitcoin nunca tendrá un checksig condicional. Si tienes transacciones inteligentes complejas que pueden tener más ... esto sólo admite que las cosas individuales tengan una única regla de firma agregada que se ejecuta en todo. Así que la única coordinación entre los scripts individuales es este punto. ¿Qué pasa si quieres un script que quiere verificar una firma de una transacción diferente. Necesitarías el checksig de la pila. .... Podrías tener un OP_IF y envolverlo, y luego pasar a la pila si quieres ejecutar esa rama de todos modos.

Puedes hacer que tus cheques sean condicionales. Hay un grupo de firmantes que tienen que estar en línea al mismo tiempo y pueden elegir tener una firma en lugar de varias. Pero puede ser condicional como lo que es ese conjunto, puedes tener ramas IF en tu script para eso. Siempre y cuando todas las diferentes entradas estén de acuerdo en lo que el combinado compartió... sí, eso es necesario. Entonces debería estar bien que las entradas individuales suban cosas a la pila compartida y luego el script de verificación que todos acordaron. Pero lo que has descrito limita esa verificación compartida que solo comprueba las firmas agregadas.. parece que podría ser bueno tener una funcionalidad más general? Tienes una pila compartida en la primera entrada la pone donde sea ... OP_CHECKSIGFROMSTACK. O un checksig especial que siempre compruebe que nunca se ha puesto en lotes. ¿Necesitamos banderas sighash? No sé qué es lo que hay que hacer. Tal y como está descrito, tus pkscripts van a depender de esta funcionalidad... podrías seguir utilizándola sin la agregación. Podrías usar el viejo operador checksig si quieres. Podrías tener una entrada que permita un checksig compatible con la agregación, y esa entrada no se hace con una firma de agregación, sólo proporcionas la firma para ella. Puede haber una razón por la que quieras algo parecido a Schnorr. Empecé a escribir una propuesta para la integración de bitcoin. Tienes el operador checksigverify, toma una pubkey, la firma hace un hash de la transacción como normal, luego toma una firma. En mi borrador, puedes proporcionar una firma real si es la primera, o simplemente proporcionas un número agregado como 0, y entonces comparte la firma con alguien más, y si no es 0 entonces es una firma. Así que podrías... si tuvieras una de estas salidas agregables, podrías gastarla sin agregación, se elige en el momento de la firma si quieres usar la agregación o no. Múltiples firmantes podrían estar en línea, y la interacción, por cierto, depende del modelo de seguridad que quieras, como 2 o 3 etapas de interacción entre los firmantes. Podríamos admitir múltiples agregados en una transacción, sería sencillo, y el argumento para hacerlo sería que, como requiere interacción, quizá algunas entradas puedan agregarse y quizá otras puedan agregarse por separado. Podríamos intentar implementarlo de ambas formas y ver qué forma es más fácil. El orden de ellos importa, cómo se ponen de acuerdo en qué cubo - probablemente lo haremos - el orden importa para la firma, debido a las entradas y salidas de las transacciones, y por razones de rendimiento tal vez las claves públicas - - eliminar las pubkeys duplicadas en la agregación, no es necesario firmar dos veces si la misma pubkey está allí. Digamos que 4 entradas en 2 pares, necesitan estar en los 2 pares correctos, de ahí viene la complejidad. Al operador checksig, le proporcionas un número de acumulador y cada acumulador necesita tener una firma y puedes tener múltiples checksigs dependientes de él. No tienes que decidir eso en el momento de la salida, es parte de la firma, los números del acumulador van en la firma. Una cosa que podrías querer hacer es poner un identificador al final de la pila compartida y decir que quieres estar seguro de que este UTXO no se gasta con este otro UTXO, y este otro pondrá un token único en la pila, comprobar que no se gasta con este otro. Esa es una propiedad de otras formas de introspección, rompe la independencia de los UTXOs. Eso es una característica general del script, no una propiedad de la agregación, con otras actualizaciones del script eso es posible por lo que no es una parte importante de la agregación. Votando por ejemplo, podrías hacer que tuvieras que tener un montón de cosas para siempre, tu cosa compartida es sumar las cantidades. Usted proporcionaría la lista de pubkeys, y usted identifica un subconjunto de ellos, y entonces usted dice para estos 51 de 100 van a firmar, usted emite un checksig para esos 51, esto es independiente de la agregación. El script se ramifica para eso.

Deberíamos explicar de dónde viene el speedup y luego explicar el lote. La razón por la que esto es más rápido es que en la verificación más rápida, esta fórmula, esta ecuación de verificación es una que pasa... diste la ecuación de firma, la ecuación de verificación es simplemente multiplicar todo por G, y entonces obtienes s*G = R - H(R || P1 || C || m)*P1 - H(R || P2 || C || m)*P2. Sí. Así que he tomado la ecuación de la firma, y se obtiene esto ... R = H(R || P1 || C || m)*P1 + ... + s*G. Esto es una suma de multiplicaciones de curvas elípticas. Hay algoritmos eficientes (Strauss, Bos-Coster, Pippenger) que calculan estas cosas más rápido que las multiplicaciones individuales y la suma de las mismas. La suma de los productos es más rápida de calcular que las multiplicaciones individuales. Para 10000 claves, el aumento de velocidad es aproximadamente 8 veces. Esto es como sobre un bloque. Pero estamos hablando de agregación de firmas, no de validación por lotes todavía. Esta es una sola ecuación en la que hay una R y luego un número de términos uno por cada pubkey y luego una sola multiplicación con G al final. Si tienes varias de estas ecuaciones para verificar, entonces puedes simplemente sumar estas ecuaciones. Esto no es seguro, pero es una toma inicial - tienes que verificar un montón de estas ecuaciones R = blah, y luego las sumas todas, y verificas sólo la suma, como una forma inicial de validación por lotes. Funciona pero no es seguro, puedes hacer cancelaciones donde tienes firmas inválidas y las cancelas en la suma o algo así. La solución es multiplicar primero cada una de las ecuaciones con un número aleatorio antes de sumarlas. No sabes la proporción entre las diferentes ecuaciones esa es la forma de proteger contra la cancelación en el otro esquema.

Esta validación por lotes básicamente hace una instancia más grande de este problema de multiexponenciación que es rápido para muchas entradas. Lo hace un poco más lento porque estás multiplicando los valores R, así que es un problema más grande. Al final, toda tu ecuación que contendrá una multiplicación para cada clave y una para cada firma. Tome el número de claves públicas en general, y el número de firmas en general, y ahora hay un tiempo por punto a medida que avanza, por lo que es completamente plausible para obtener 4000 entradas, porque usted toma todas las cosas ya que no tenemos un .... Pieter está buscando el gráfico ahora, supongo. Que de alguna manera proyectará en la pizarra.

¿Qué porcentaje del tiempo de validación del bloque es la validación de la firma? En la descarga inicial de bloques, es casi todo. Suponiendo que no tengas las firmas validadas ya. Es una mayoría. Digamos que es el 50%. ¿Cuál es el aumento de velocidad en la verificación de las 2 entradas 2 salidas y se supone que se agregan juntos, por lo que este es el número 2. Entonces, ¿estamos hablando de antminer aquí? Cuando estás poniendo cosas en el mempool es un factor de 1,5x, y cuando tienes un bloque entero, significativamente más. Y la agregación reduce el tamaño de las transacciones por la cantidad de entradas que tienen. En nuestro documento, fuimos e hicimos números sobre la reducción basada en los patrones de transacción existentes, hubo una reducción del 28% basada en la historia existente. No tiene en cuenta la agregación de claves o cómo el comportamiento cambiaría en la red como resultado de esto.

Entendemos cómo el lote obtiene un aumento de velocidad;... y eso sólo se aplica a los bloques completos, a la descarga inicial de bloques, y en la punta estamos almacenando en caché todo y aparece un bloque... bueno, también en el caso adverso. Luego está lo que me gusta, que es sumar los valores de s y tener G al final. En lugar de usar un generador de números aleatorios para la validación del lote, puedes usar un RNG determinista que use el hash del bloque excluyendo los testigos o algo así como tu semilla, y ahora el minero puede precalcular estas ecuaciones R y en lugar de... todos los valores s pueden sumarse, y debería haber sólo una única s combinada para todo el bloque y cada firma individual sólo tendría su R premultiplicada. Hay todo tipo de retos para esto, como que ya no se valida individualmente, habría que validar todo el bloque. Ya no puedes almacenar en caché las transacciones como validación. Se utiliza el hash del bloque; se toma la raíz de merkle tal cual, y... así que tendría que volver a calcular si quiere.. Es la mitad del tamaño de todas las firmas además de lo que lograría la agregación. Sólo está agregando los valores s, así que tienes esta firma que es una pequeña parte de una transacción y compartes la mitad, así que porcentualmente no es un gran cambio. No te da ningún aumento de velocidad de la CPU. Te ahorra tener que hacer estas multiplicaciones con los valores s sumándolos, pero eso es aritmética escalar rápida, como microsegundos para un bloque completo.

Cuantas más entradas tengas, más ganas porque añades un coste compartido de pagar por una firma, que es una ventaja muy pequeña pero que da un incentivo financiero hacia coinjoin. Porque dos transacciones tendrán dos firmas, así que esto incentiva a coinjoin que tendrá una firma que es más barata. Cuando haces una transacción, también aumenta tu incentivo para barrer pequeños UTXOs.

Puedes hacer una validación por lotes a través de múltiples bloques, sí. La multiexponenciación acelerada es un algoritmo secuencial, así que ¿cómo lo haces con múltiples núcleos? Así que si validas toda la cadena en un gran lote, sólo haces un núcleo para eso. Posiblemente pueda haber versiones multihilo de esto si pensamos en hacer millones a la vez, puede tener sentido investigarlo. Hemos estado buscando algoritmos eficientes para la multiexponenciación. Andrew implementó uno, Jonas Nick implementó uno, es una combinación novedosa de partes, y quizás deberíamos escribir sobre ello.

El artículo de la FC17 no se publicó (fue rechazado) debido al trabajo multisig de Bellare-neven, por lo que vamos a preparar algo más, o simplemente pedirnos el artículo anterior.

Estos algoritmos de multiplicación probablemente entrarán en libsecp256k1 incluso sin agregación. Y luego escribir un BIP. Simplificamos este proceso porque antes de que tuviéramos este esquema de delineación personalizado... teníamos este trozo extra en el que teníamos que conseguir la revisión pública de los criptógrafos. Bellare-Neven es ampliamente revisado y bien conocido. Buscamos esto por un tiempo, pero recién ahora la gente lo está sugiriendo. Encontramos muchos artículos que ignoraban el problema de la cancelación. Lo llaman "multi-firma". El título del artículo hace que sea difícil de encontrar: “Firma múltiple en el modelo de clave pública simple y un lema general de bifurcación”. Su contribución más importante fue demostrar que esto es seguro (y su estrategia para ello).

Conseguir la criptografía terminada y probada en libsecp256k1, y simultáneamente con eso, creamos un BIP para bitcoin que implementará una nueva versión de script, que tiene un nuevo operador checksig y tal vez algunas otras cosas se montarán juntas en eso. Así que redefinimos checksigs para que sea esto, o tal vez esta sea la única mejora en esta versión de script. Parece que el tipo de firma diferente es una cosa más básica más fácil de entender, y la agregación es otra capa en la parte superior de este. Firmas un poco más pequeñas, y tenemos la agregación schnorr, pero puedes hacer agregación en ECDSA pero es bastante complejo de implementar y básicamente nadie lo ha implementado. Y estas otras cosas son más bien un par de cientos de líneas de código. La agregación para schnorr es bastante fácil. Si introduces un nuevo tipo de firma, puedes hacer la validación por lotes, pero también puedes hacer la validación por lotes con ECDSA incluyendo 1 bit extra con cada firma. Me preocupa que parezca un .... El mayor obstáculo aquí es que cruza una capa, estamos introduciendo una cosa de comprobación de scripts a nivel de transacción, bueno checklocktimeverify que es un nivel de transacción.... La agregación de la firma a través de las entradas; checklocktimeverify es algo que se verifica dentro del script que mira la transacción. Pero estas otras cosas son más como locktime más que checklocktimeverify. Todavía tienes que mirar las firmas. Este es un nuevo nivel de validación que se introduce. Creo que vale la pena, pero es algo complicado. Tienes este nuevo contexto de validación donde puedes introspeccionar cosas que antes no podías hacer.. No, no hay introspección. Es sólo agregación. Estás fusionando firmas juntas. Eso es todo. No deberías añadir otros pilotos a este tipo de actualización; si quieres hacerlo, introduce otra versión de script que no toque la criptografía.

En cada salida, hacer que cada entrada parezca indistinta. Ese es uno de mis objetivos. Nadie en la red debería ser capaz de ver cuál es su guión. Este es un paso hacia esto. Tiempo de validación sin importar lo complejo que sea tu script. Sólo tienes que probar que el script existió, es válido, y el hash. Pero cualquier cosa que complique más la estructura de la transacción. Esto ayuda a la fungibilidad, la privacidad y el ancho de banda. Tener unas condiciones a nivel de transacción a través de entradas.... comprobando la tasa de agregación para su transacción. La suma de las entradas tiene que ser mayor que la suma de las salidas. Esto es similar a las razones de la secuencia de comandos sin guión.

Simultáneamente con una unidad de trabajo, calcula una raíz cuadrada recíproca al mismo tiempo que la inversa. A partir de uno de los Bouncycastle desarrolladores. Él usó esto para idear una manera de hacer una X-sólo para libsecp(?)... y sacas sólo la X. Con el costo de una descompresión extra, ... la X correcta. Tienes como una X y tienes tu escalar, y tomas la X y hay un isomorfismo a un punto jacobiano en una curva isomórfica. Ahora lo has convertido en una curva isomórfica con coordenadas x, x al cuadrado, x al cubo o algo así, y entonces puedes multiplicar eso por ... ... y obtienes este punto al final que está en coordenadas proyectivas.. y así para obtener el valor correcto usando esa proyección de una curva isomórfica a la curva correcta, puedes hacer una raíz cuadrada, puedes mover la raíz cuadrada del principio al final. Tienes que hacer una inversa para salir de las coordenadas. Es super rápido ECDH para esta curva, y ese es el gran impulsor de las curvas de cofactor 2, ... necesitas hacer el multiplicador de Montgomery que sólo funciona en curvas con un cierto cofactor. Tal vez ponerlo en BIP151. Se guarda un byte, así....

Todas las cosas de 32 bytes están invertidas, y todas las de 20 bytes están en el sentido correcto. El RPC lo devuelve de la otra manera. El RPC escribe las cosas de 20 bytes del modo correcto. Bitcoin las muestra todas al revés. Bitcoin interpreta las secuencias de 32 bytes como formato bigint little-endian, impreso a los usuarios como big-endian. Todo es little-endian.

https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html

https://eprint.iacr.org/2018/068