La propuesta de BIP "Softfork Temporal de Datos Reducidos" sugiere deshabilitar temporalmente varias características de Bitcoin en consenso. He analizado la blockchain para cuantificar el impacto potencial, identificando transacciones históricas que violan cada una de estas reglas. 🧵↓

Regla #1: "Los nuevos scripts de salida scriptPubKeys que excedan los 34 bytes son inválidos, a menos que el primer opcode sea OP_RETURN, en cuyo caso se permiten hasta 83 bytes." Esto afecta a todas las salidas P2PK y P2MS, así como a un pequeño número de SPKs no estándar.

Regla #2: "OP_PUSHDATA* con cargas útiles mayores de 256 bytes son inválidas, excepto para el push de redeemScript en las scriptSigs de BIP16." Asumo que esto solo se aplica a los pushes de datos *ejecutados*, así que he excluido los pushes dentro de los sobres de inscripción de taproot, de los cuales hay muchos.

Regla #3: "Gastar versiones de testigos (o Tapleaf) indefinidas (es decir, no Witness v0/BIP 141 ni Taproot/BIP 341) es inválido." Hay poco más de 54k transacciones con números de versión indefinidos (principalmente utilizando salidas falsas para eludir el límite de op_return).

Sin embargo, los BIPs 141 y 341 definen longitudes específicas para los programas de testigos: - v0, longitud 20 (P2WPKH) - v0, longitud 32 (P2WSH) - v1, longitud 32 (P2TR) como está escrito, RDTS parece prohibir todas las demás longitudes de programa, incluyendo los anclajes P2A (v1, longitud 2).

Regla #4: "Las pilas de testigos con un anexo de Taproot son inválidas." Hasta ahora, 11 transacciones han adjuntado un anexo a los gastos de taproot, principalmente para jpegs.

Regla #5: "Los bloques de control de Taproot más grandes de 257 bytes (un árbol de Merkle con 128 hojas de script) son inválidos." Hay ~32k gastos de taproot que claramente incrustan datos con una profundidad de bloque de control de 100+ (labitbus y similares). Pero también hay un puñado de gastos "legítimos" a menor profundidad.

Regla #6: "Los Tapscripts que incluyan opcodes OP_SUCCESS* en cualquier lugar (incluso no ejecutados) son inválidos." Hay dos gastos históricos de taproot que incluyen opcodes OP_SUCCESS: la transacción de Burak, el rompedor de lightning, y esta tonta demostración de OP_CAT.

Regla #7: "Los tapscripts que ejecutan la instrucción OP_IF o OP_NOTIF (independientemente del resultado) son inválidos." Esto tiene como objetivo deshabilitar el "sobre de inscripción", que ha sido utilizado en más de 104 millones de transacciones hasta ahora.

Sin embargo, RDTS va más allá de deshabilitar el sobre de inscripción, prohibiendo completamente OP_IF y OP_NOTIF. Alrededor de 70 transacciones no inscritas han utilizado OP_IF en scripts de taproot. Muchos son experimentos al estilo bitvm, pero también hay ejemplos de usos financieros más sencillos.

Por ejemplo, hay un par de gastos utilizando esta plantilla de script de "multisig en decadencia", que utiliza múltiples OP_IFs

Lo más preocupante es que hay múltiples gastos de una billetera que utiliza esta plantilla de script HTLC detrás de un punto NUMS bip341 (deshabilitando la ruta de clave) El script utiliza OP_IF para elegir entre una rama que requiere dos firmas y una preimagen hash, o una firma después de un tiempo de espera relativo.

Los defensores de RDTS han desestimado las preocupaciones sobre la confiscación relacionadas con OP_IF y grandes bloques de control en taproot, afirmando que los usuarios siempre pueden gastar a través de la ruta clave en su lugar. Sin embargo, alrededor de 560k transacciones han gastado salidas de taproot donde la ruta clave estaba comprobablemente deshabilitada.