2 de 3 multigrado con firmas Schnorr

Por lo que entiendo, las firmas de Schnorr permitirán transacciones de múltiples firmas n-of-n, sin embargo, m-of-n no es posible usando solo la ruta clave.

Eso no es del todo exacto. Las firmas de Schnorr, como se describe en BIP340, son puramente 1-clave-1-firma.

Existen esquemas alternativos, que son compatibles con la validación BIP340.

• Uno es MuSig (1,2,DN) que permite n de n firmas, verificables contra una única clave pública agregada, que representa el acuerdo de todas las claves constituyentes.
• Otro es FROST, que permite umbrales arbitrarios de k-de-m, verificables de manera similar con una sola clave. Sin embargo, necesita una configuración interactiva, en la que los cosignatarios (potenciales) deben cooperar (mientras tienen acceso a sus claves privadas) para construir la clave agregada, por lo que no es compatible con, por ejemplo, tener una billetera multisig cuyas direcciones se derivan sobre la marcha. mediante claves BIP32. También carece de rendición de cuentas: después del hecho, no se puede saber qué partes firmaron.

Supongamos que necesitamos un esquema 2 de 3. Por lo que puedo decir, podemos usar un esquema 3 de 3 y simplemente dar a cada parte dos de las tres llaves de tal manera que cualquiera de las dos partes cuando se combinen tendrá las tres llaves. (Una parte obtiene las claves A y B, otra obtiene B y C y la última obtiene A y C).

¿Funcionaría este método? ¿Hay algún problema que no veo?

Sí, esto es posible. Si genera las 3 claves en una máquina, obtiene un modelo de seguridad poco interesante, ya que aparentemente las 3 tienen una máquina en la que confía para generar la clave honestamente. Probablemente podría aceptar igualmente dejar que esa máquina haga la firma.

Una variante de lo que sugiere es quizás más interesante: cada una de las 3 partes genera 1 clave y le da la clave privada a su vecino de la derecha. Ahora cualquier subconjunto de 2 de ellos tiene las 3 claves.

Existen más esquemas como este. El más simple es un esquema 1 de n de configuración interactiva que no se puede contabilizar: una parte genera una clave nueva y se la da a todos los demás. Hecho.

Sin embargo, no recomiendo usar esto, aunque engañosamente simple, el diablo está en los detalles para hacer que tales esquemas sean seguros, y probablemente sea mejor usar FROST o algo similar en su lugar, ya que está bien analizado.

Si desea responsabilidad o una configuración no interactiva (la capacidad de generar direcciones sin tener las claves del cofirmante en línea), ninguno de estos enfoques es suficiente y probablemente debería usar (en el contexto de BIP341) un árbol donde cada hoja es un 2 de 2 musig agregado de 2 de 3 subconjuntos.