¿Cuáles son las diferentes funciones de actualización en la propuesta BIP-Taproot (BIP 341)?

¿Cuáles son las diferentes funciones de actualización en la propuesta BIP-Taproot (BIP 341) ?

¿Por qué hay tantas rutas de actualización? ¿Hay algo que un anexo pueda hacer que una versión hoja no pueda?

Esta pregunta la hizo James Prestwich en Twitter .

Respuestas (1)

Existe el anexo, la versión de hoja, ext_flag, OP_SUCCESS, tipos de claves públicas desconocidas y probablemente también podría incluir la versión testigo existente. Creo que esa lista es exhaustiva .

El ext_flag no es tanto un mecanismo de extensión en sí mismo; más una estructura que permite reutilizar de forma segura el código sighashing (en lugar de necesitar una nueva etiqueta u otro mecanismo para evitar colisiones).

  • Versiones hoja: para renovar la semántica del script
  • OP_SUCCESSx: para nuevos códigos de operación, sin coordinar la nueva versión
  • Tipos de clave pública: para nuevas banderas sighash/criptografía sin necesidad de una explosión de nuevos códigos de operación
  • Anexo: para agregar efectivamente nuevos campos como nLockTime

Las versiones hoja en realidad solo se agregaron porque teníamos algunos bits de sobra en el bloque de control, y parecía un desperdicio reservarlos. En su mayoría, son una conveniencia, creo, ya que OP_SUCCESSx puede lograr lo mismo (agregar un OP_V2, etc.).

Como scriptPubKey no compromete el anexo, es más una forma de ampliar las posibilidades de testigo que directamente una forma de agregar nueva semántica.

Entonces, ¿hay algo que un anexo pueda hacer que una nueva versión de hoja no pueda? Creo que son ortogonales.

Por ejemplo, una función en la que podría restringir un tx para que solo sea válido en una cadena que contenga un determinado hash de bloque. No se puede hacer con una versión de hoja, ya que es una cuestión de hora de inicio de sesión. Creo que el anexo no se puede usar para introducir nuevas condiciones de script. Una nueva versión de hoja podría introducir su propio anexo, pero eso no podría aplicarse a las versiones de hoja anteriores.

El ejemplo motivador para el anexo es este. Imagine que se agrega un nuevo código de operación que necesita pocos bytes pero tiene un alto costo de CPU. Querría un presupuesto de alto peso por tal código de operación, pero eso puede requerir realmente rellenar el testigo con datos ficticios solo para obtener el presupuesto necesario. En cambio, sería bueno si pudiera haber un marcador en la entrada que diga "incrementar el peso aparente (y el presupuesto operativo correspondiente) en N", sin tomar N bytes. Logísticamente, sería molesto si ese marcador solo se puede analizar cuando la salida gastada está disponible. El anexo es reconocible sin contexto, principalmente al explotar una afortunada coincidencia sobre qué conjunto de testigos es válido para v0 (el primer byte del último elemento de la pila de testigos solo puede tomar ciertos valores de byte). Esto, creo, no se puede lograr con una nueva versión de hoja.

Esta pregunta fue respondida por Pieter Wuille en Twitter .