Crítica a la Propuesta de Soft Fork
El desarrollador y analista de Mempool.space, Mononaut, ha publicado una crítica detallada advirtiendo que la propuesta de «Reduced Data Temporary Softfork» podría deshabilitar tipos de transacciones legítimas en toda la red. Esta nueva propuesta de soft fork, diseñada para frenar el almacenamiento excesivo de datos en la blockchain de Bitcoin, ha recibido críticas contundentes en tiempos recientes. El miércoles, Mononaut publicó una evaluación que describe el posible daño colateral que el conjunto de reglas podría causar.
Detalles de la Propuesta RDTS
La propuesta, conocida como Reduced Data Temporary Softfork (RDTS), introduce un conjunto de restricciones a nivel de consenso destinadas a reducir las transacciones que consumen muchos datos, un esfuerzo que los desarrolladores consideran 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 los scriptPubKeys a 34 bytes, estableciendo un límite de 83 bytes para las salidas de OP_RETURN, restringiendo los bloques de control de Taproot, prohibiendo versiones de testigos indefinidas y deshabilitando categorías enteras de lógica de Tapscript.
Impacto de las Restricciones
Los defensores del BIP argumentan que estas 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 se incrustara material ilegal en la cadena. Sin embargo, la evaluación de Mononaut cuantifica las repercusiones prácticas de esas restricciones al revisar la actividad histórica de la blockchain para identificar qué transacciones reales habrían violado las reglas propuestas. Sus hallazgos sugieren una interrupción significativa. Bajo el límite de tamaño de scriptPubKey por sí solo, todas las salidas de pay-to-public-key (P2PK) y multisig (P2MS) serían inválidas. Esta restricción también afectaría a un pequeño número de salidas no estándar en transacciones pasadas.
Consecuencias de las Nuevas Reglas
Una de las reglas más amplias—invalidar las operaciones de OP_PUSHDATA con cargas útiles superiores a 256 bytes—no afectaría a los sobres de inscripción, asumiendo que solo las cargas ejecutadas califiquen. Sin embargo, Mononaut enfatizó que las versiones de testigos indefinidas impactarían más de 54,000 transacciones históricas, muchas de las cuales utilizaron salidas no convencionales para eludir los límites de datos de OP_RETURN. Dado que las longitudes de las versiones de testigos están definidas de manera estricta en los BIPs 141 y 341, la propuesta tal como está redactada incluso bloquearía algunos formatos modernos válidos, como los anclajes P2A.
Transacciones Afectadas
Mononaut también detalló que RDTS invalidaría las pilas de testigos que contienen un anexo de Taproot. Aunque es raro, el desarrollador de Mempool.space señala que al menos 11 transacciones han utilizado un anexo para fines que consumen muchos datos. Una categoría más significativa, enfatizó Mononaut, son los grandes bloques de control de Taproot: aproximadamente 32,000 gastos pasados incluyen bloques de control de profundidad 100+, a menudo utilizados para la 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 a una profundidad de bloque de control de 11, que sería rechazada bajo RDTS.
Argumentos a Favor y en Contra
Los puntos más estrictos de la propuesta—prohibiendo OP_SUCCESS y cualquier Tapscript que ejecute OP_IF o OP_NOTIF—van mucho más allá de los sobres de inscripción. Mononaut destaca dos transacciones históricas de OP_SUCCESS, incluida la transacción rompedora de rayos de Burak, y aproximadamente 70 gastos de Taproot basados en OP_IF no relacionados con la inscripción. Varios de estos son primitivas financieras, incluidos plantillas de multisig en decadencia y diseños de contratos bloqueados por tiempo de hash (HTLC). Algunos provienen de billeteras que deshabilitaron intencionalmente su ruta de clave, dejando el gasto por ruta de script como la única forma de mover fondos.
Los defensores de RDTS han argumentado que los usuarios con scripts afectados podrían recurrir al gasto por ruta de clave. Sin embargo, los datos de Mononaut desafían esa suposición directamente: aproximadamente 560,000 gastos históricos de Taproot provienen de salidas cuya ruta de clave estaba comprobablemente deshabilitada, haciendo que OP_IF y funciones similares sean esenciales en lugar de opcionales.
Conclusión
Los partidarios del soft fork temporal mantienen que RDTS es una medida protectora a corto plazo diseñada para preservar la utilidad monetaria de Bitcoin, prevenir riesgos legales y reducir las cargas de los nodos limitando el almacenamiento de datos. Los críticos contraargumentan que las amplias restricciones sobre el comportamiento de Tapscript corren el riesgo de introducir censura de facto, deshabilitando tipos de transacciones válidas y rompiendo aplicaciones existentes. Este debate refleja disputas anteriores sobre el crecimiento de datos impulsado por la inscripción, reflejando desacuerdos más profundos sobre si Bitcoin debería seguir siendo estrictamente monetario o continuar acomodando usos experimentales. A medida que la propuesta permanece en forma de borrador, la discusión continúa entre desarrolladores, investigadores y participantes del ecosistema.
