El BIP "Reduced Data Temporary Softfork" propone deshabilitar temporalmente varias funciones de Bitcoin por consenso. He estudiado la cadena de bloques para cuantificar el impacto potencial, identificando transacciones históricas que violan cada una de estas reglas. 🧵↓

Regla #1: "Las nuevas scriptPubKeys de salida que superen los 34 bytes no son válidas, a menos que el primer código de operación sea OP_RETURN, en cuyo caso hasta 83 bytes son válidos". Esto afecta a todas las salidas P2PK y P2MS, así como a un pequeño número de SPK no estándar.

Regla #2: "OP_PUSHDATA* con cargas útiles de más de 256 bytes no son válidas, excepto para la inserción de redeemScript en BIP16 scriptSigs". Supongo que esto solo se aplica a las inserciones de datos *ejecutadas*, por lo que he excluido las inserciones dentro de los sobres de inscripción de raíz principal, 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) no es válido". Hay poco más de 54k transacciones con salidas de número de versión indefinidas (en su mayoría usando salidas falsas para eludir el límite de op_return).

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

Regla #4: "Las pilas de testigos con un anexo de Taproot no son válidas". Hasta ahora, 11 transacciones han adjuntado un anexo a los gastos de raíz principal, principalmente para jpegs.

Regla #5: "Los bloques de control de raíz principal de más de 257 bytes (un árbol de Merkle con 128 hojas de script) no son válidos". Hay ~ 32k obviamente gastos de raíz principal de incrustación de datos con una profundidad de bloque de control de 100+ (labitbus y similares). Pero también un puñado de gastos "legítimos" a menor profundidad.

Regla #6: "Los scripts de acceso que incluyen códigos de operación OP_SUCCESS* en cualquier lugar (incluso sin ejecutar) no son válidos". Hay dos gastos históricos de raíz de grifo que incluyen códigos de operación OP_SUCCESS: la transacción romperayos de Burak y esta tonta demostración de OP_CAT

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

Sin embargo, RDTS va más allá de deshabilitar el sobre de inscripción, prohibiendo OP_IF y OP_NOTIF por completo. Alrededor de 70 transacciones sin inscripción han utilizado OP_IF en scripts de raíz principal. Muchos son experimentos al estilo bitvm, pero también hay ejemplos de uso financiero más sencillo.

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

Lo más preocupante es que hay múltiples gastos desde una billetera que usa esta plantilla de script HTLC detrás de un punto NUMS bip341 (deshabilitando la ruta de la 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 de confiscación relacionadas con OP_IF y grandes bloques de control en taproot al afirmar que los usuarios siempre pueden gastar a través de la ruta de la llave. Sin embargo, alrededor de 560k transacciones han gastado salidas de raíz principal donde la ruta de la clave estaba deshabilitada de manera demostrable.