Flags de Desarrollador Riesgos Importantes en el Propuesto Soft Fork de Reducción de Datos de Bitcoin

Revisión de Datos de Transacciones Muestra que RDTS Podría Bloquear Usos Clave de Bitcoin

Una nueva propuesta de soft fork diseñada para frenar el almacenamiento excesivo de datos en la blockchain de Bitcoin está generando duras críticas en tiempos recientes. El miércoles, el analista independiente y desarrollador de mempool.space, Mononaut, publicó una evaluación que describe el potencial daño colateral que el conjunto de reglas podría causar.

La propuesta, conocida como el Softfork Temporal de Datos Reducidos (RDTS), introduce un conjunto de restricciones a nivel de consenso destinadas a reducir las transacciones pesadas en datos—un esfuerzo que los desarrolladores dicen es necesario tras la actualización de Bitcoin Core v30 que eliminó los límites en los datos de OP_RETURN.

RDTS se aplicaría durante aproximadamente un año si se activa, limitando scriptPubKeys a 34 bytes, limitando las salidas OP_RETURN a 83 bytes, restringiendo los bloques de control de Taproot, prohibiendo versiones de testigos indefinidas y deshabilitando categorías enteras de la lógica Tapscript. Los defensores del BIP argumentan que las medidas actúan como un freno de emergencia contra las cargas de datos arbitrarias que podrían exponer a los operadores de nodos a responsabilidad legal si material ilegal se incrustara en la cadena.

La evaluación de Mononaut, sin embargo, cuantifica las consecuencias prácticas de esas restricciones revisando la actividad histórica de la blockchain para ver qué transacciones reales habrían violado las reglas propuestas. Sus hallazgos sugieren una disrupción significativa. Bajo el límite de tamaño de scriptPubKey por sí solo, todas las salidas de pago a clave pública (P2PK) y multisig (P2MS) serían inválidas. Esa restricción también afecta a un pequeño número de salidas no estándar en transacciones pasadas.

Una de las reglas más amplias—invalidando operaciones OP_PUSHDATA con cargas superiores a 256 bytes—no afectaría a sobres de inscripción, asumiendo que solo empujes ejecutados califiquen. Pero Mononaut enfatizó que las versiones de testigos indefinidas impactarían más de 54,000 transacciones históricas, muchas de las cuales usaron salidas no convencionales para sortear los límites de datos OP_RETURN. Debido a que las longitudes de versión de testigos están definidas estrictamente en BIPs 141 y 341, la propuesta tal como está escrita incluso bloquearía algunos formatos modernos válidos como anclajes P2A.

También lea: Desarrolladores de Bitcoin Core Fusionan Cambios de Política Controversiales: ¿Se Aproxima un Fork?

Mononaut detalló que RDTS también invalida pilas de testigos que contienen un anexo de Taproot. Aunque raro, el desarrollador de mempool.space señala que al menos 11 transacciones han usado un anexo con fines de datos pesados. Una categoría más significativa, enfatizó Mononaut, son los grandes bloques de control de Taproot: alrededor de 32,000 gastos pasados incluyen bloques de control de profundidad 100+ a menudo utilizados para incrustación de datos, pero incluso algunos experimentos no relacionados con datos dependen de configuraciones más pequeñas y legítimas que serían deshabilitadas. Una dirección activa gasta consistentemente en una profundidad de bloque de control 11, lo cual sería rechazado bajo RDTS.

Los términos más estrictos de la propuesta—prohibir OP_SUCCESS* y cualquier Tapscript que ejecute OP_IF u OP_NOTIF—van más allá de los sobres de inscripción. Mononaut destaca dos transacciones históricas de OP_SUCCESS, incluyendo la transacción que interrumpió Lightning de Burak, y aproximadamente 70 gastos de Taproot basados en OP_IF no relacionados con inscripción. Varios de estos son primitivos financieros, incluyendo plantillas multisig decaying y diseños de contratos bloqueados por tiempo-hash (HTLC). Algunos provienen de billeteras que intencionalmente deshabilitaron su keypath, dejando el gasto de script-path como la única manera de mover fondos.

Los defensores de RDTS han argumentado que los usuarios con scripts afectados podrían recurrir al gasto de keypath. Sin embargo, los datos de Mononaut desafían directamente esa suposición: alrededor de 560,000 gastos históricos de Taproot provienen de salidas cuyo keypath fue deshabilitado por prueba, haciendo que OP_IF y funciones similares sean esenciales más que opcionales.

Los partidarios del soft fork temporal mantienen que RDTS es una medida de protección a corto plazo diseñada para preservar la utilidad monetaria de Bitcoin, prevenir riesgos legales y reducir las cargas en los nodos al limitar el almacenamiento de datos. Los críticos argumentan que las amplias restricciones sobre el comportamiento de Tapscript corren el riesgo de introducir censura de facto, deshabilitando tipos de transacciones válidos y rompiendo aplicaciones existentes.

El debate refleja disputas anteriores sobre el crecimiento impulsado por inscripciones de datos, reflejando desacuerdos más profundos sobre si Bitcoin debería permanecer estrictamente monetario o continuar acomodando usos experimentales. Dado que la propuesta permanece en forma de borrador, la discusión sigue en curso entre desarrolladores, investigadores y participantes del ecosistema.

FAQ ❓

• ¿Qué es RDTS?
  Una propuesta de soft fork temporal que restringe varias características de script y datos de Bitcoin.
• ¿Por qué se debate RDTS?
  Los partidarios desean frenar el abuso de datos, mientras que los críticos dicen que deshabilita transacciones válidas.
• ¿Qué encontró Mononaut?
  Su análisis muestra que muchas transacciones históricas fallarían bajo las reglas RDTS.
• ¿Cuánto tiempo duraría RDTS?
  La propuesta describe una ventana de activación de un año si se adopta.