¿Qué hace que la agregación de firmas de entrada cruzada sea complicada de implementar? Además de por razones de espacio de diseño, ¿por qué no se convirtió en BIP-Taproot? (La agregación de claves dentro de una entrada se puede lograr con MuSig, MuSig2, etc., pero las firmas no se pueden agregar a través de diferentes entradas con BIP-Taproot).
Esta pregunta fue hecha por Thorkil Vaerge en Twitter .
Pieter Wuille respondió esto en Twitter .
La complicación más importante de la agregación de entrada cruzada se explica en esta publicación de la lista de correo de desarrollo de Bitcoin de AJ Towns.
TL; DR: si los softforks cambian las firmas que se verifican, no deben cambiar lo que se agrega. Esto es especialmente complicado cuando interactúan con el mecanismo de actualización OP_SUCCESSx de BIP341, que fácilmente podría permitir que futuros softforks cambien la semántica del script por completo. No hay nada fundamentalmente difícil aquí, es solo complejidad de ingeniería para asegurarse de que todo funcione bien en conjunto.
Pieter agregó en un seminario socrático de BitDevs en Londres sobre BIP-Taproot:
El injerto y la agregación de insumos cruzados son cambios tan profundamente conceptuales. No puedes permitir construirlos más tarde. Es un cambio tan estructural en cómo funcionan los scripts. Estas cosas no son algo que se pueda agregar más tarde sobre Taproot. Necesitas un sucesor. Agregación de entrada cruzada, el concepto de verificación de script ya no es por entrada, sino por transacción. No puedes hacerlo con una eficiencia óptima, supongo que puedes inventar cosas. El tipo de extensibilidad que se incorpora son nuevos códigos de operación, nuevos tipos de claves públicas, nuevos tipos de sighash, todas estas cosas se hacen bastante fáciles y casi no tienen inconvenientes en comparación con no hacerlo de inmediato. Cambios estructurales reales en la ejecución del script, necesitan algo más.
nilskp
miguel folkson
miguel folkson