Anexo de Taproot

BIP-341 reservó el campo para futuras bifurcaciones blandas (soft forks) y no le dio ningún significado, así que hoy ningún nodo lee su contenido. La función IsWitnessStandard de Bitcoin Core rechaza un gasto Taproot que lleve un anexo etiquetado con 0x50, de modo que la transacción no se retransmitirá, y BIP-341 advierte que puede provocar una pérdida permanente de fondos. Las billeteras no tienen ningún motivo para añadir uno, por lo que nada de lo que usted haga al comprar o conservar bitcoin depende de él.

Cómo funciona

Un anexo de Taproot se identifica por su posición y no por un campo con nombre propio en el formato de la transacción. Si una entrada Taproot lleva al menos dos elementos en su testigo y el primer byte del último elemento es 0x50, ese elemento es el anexo y se elimina de la pila del testigo antes de examinar cualquier otra cosa. Solo entonces decide un nodo qué tiene delante: un elemento restante significa un gasto por ruta de clave, y dos o más, un gasto por ruta de script.

BIP-341 eligió 0x50 a propósito. Las versiones de hoja van en parejas de un valor par y otro impar que no deben confundirse con el primer byte de un testigo P2WPKH o P2WSH, y 0x50 era un valor sobrante sin pareja, así que era el que menos versiones futuras de script costaba. La regla también funciona a la inversa: una versión de hoja no puede ser 0x50, porque un bloque de control que empezara por ese byte no se podría distinguir de un anexo.

Lo que el anexo no hace es influir en la validación. BIP-341 dice que el campo "is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation." (siempre lo cubre la firma y cuenta para el peso de la transacción, pero por lo demás se ignora durante la validación de Taproot). Todo mensaje de firma de Taproot lleva un campo spend_type de un byte igual a (ext_flag * 2) + annex_present y, cuando hay un anexo, el mensaje lleva además el campo sha_annex, el hash SHA256 de 32 bytes del prefijo de longitud del anexo y del propio anexo, byte 0x50 incluido. La ausencia queda firmada con la misma firmeza que la presencia, así que nadie puede añadir un anexo a su transacción en la mempool ni quitarle uno. BIP-341 sitúa el mensaje de firma en 174 bytes, menos 49 con ANYONECANPAY, menos 32 con NONE y más 32 cuando hay un anexo, con un máximo de 206.

Dónde aparece

En el uso corriente no se ve ningún anexo de Taproot, y eso indica que el diseño funciona. La política de retransmisión de Bitcoin Core, en src/policy/policy.cpp, comprueba cada entrada de versión de testigo 1 con un programa de testigo de 32 bytes y devuelve false cuando el testigo contiene dos o más elementos y el último empieza por la constante ANNEX_TAG, definida como 0x50 en src/script/script.h. El comentario junto a esa comprobación es toda la política: "Annexes are nonstandard as long as no semantics are defined for them." (los anexos no son estándar mientras no se les defina ninguna semántica). Una transacción que lleve uno es válida por consenso e imposible de entregar en la práctica: un nodo con la configuración predeterminada la descarta en lugar de retransmitirla.

Un anexo aparece de verdad en un solo lugar: en cada firma Taproot que usted haya hecho alguna vez, cuyo spend_type lleva un bit con valor cero que dice que aquí no hay anexo. Ese compromiso es lo que permitiría aprovechar una futura bifurcación blanda: BIP-341 menciona como función prevista indicar el costo de validación de opcodes (códigos de operación) nuevos y caros sin que un nodo tenga que obtener la salida que se gasta.

Anexo de Taproot frente a OP_RETURN

El opcode OP_RETURN es el hueco que bitcoin designa para publicar bytes que nadie gastará, y el anexo de Taproot no es en absoluto un hueco de publicación. De ambos se dice que son espacio para datos que el consenso ignora, y se comportan de formas opuestas. Los datos OP_RETURN viven en una salida, forman parte de la transacción que todo nodo valida y anuncian un único significado acordado: aquí no hay nada gastable. Los bytes del anexo viven en el testigo, se eliminan antes de leer la pila y llevan una advertencia de la propia especificación: "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS." (los usuarios no deberían incluir el anexo en las transacciones, o puede provocar una pérdida permanente de fondos).

Esa advertencia no es un adorno. Una bifurcación blanda solo puede añadir reglas, así que unos bytes que hoy se ignoran pueden rechazarse mañana, y su firma cubre el anexo, por lo que usted no puede quitarlo de una transacción ya firmada. Quien prefirme gastos con años de antelación, como hace una bóveda o un canal Lightning, quedaría atado a un campo cuyo significado nadie ha escrito todavía.