1) Qué es, quién lo publicó y cuándo.
Nombre: “Reduced Data Temporary Softfork”.
Autor: Dathon Ohm.
Capa / tipo: Consensus (soft fork).
Estado actual: Draft (borrador; no es estándar/aceptado como BIP final). raw.githubusercontent.com/bitcoin/bips/m…
Asignado: 2025-12-03
Hilo de discusión principal: lista de correo Bitcoin Development Mailing List.
Contexto declarado por el autor en la lista: propone avanzar por la adopción de Bitcoin Core v30 y la necesidad de “reafirmar” que Bitcoin es dinero y no almacenamiento de datos.
2- Objetivo (lo que intenta lograr)
BIP-110 busca limitar temporalmente (1 año) ciertos vectores de “datos arbitrarios” a nivel consenso, para:
desincentivar usos tipo almacenamiento (ej. “inscriptions”),
reducir carga a operadores de nodos,
y “refocalizar” la red en pagos/dinero.
3) Qué cambia exactamente (reglas de consenso que propone)
Durante una ventana temporal de 1 año, un bloque sería inválido si incluye transacciones que violen estas reglas (resumen fiel del BIP):
scriptPubKey de outputs > 34 bytes ⇒ inválido, excepto OP_RETURN permitido hasta 83 bytes.
PUSHDATA / elementos de witness > 256 bytes ⇒ inválido (con excepción específica para el push del redeemScript en BIP16).
Gastar “witness/tapleaf versions” no definidos ⇒ inválido (solo permitiría v0 / Taproot / P2A).
Taproot annex ⇒ inválido.
Taproot control blocks > 257 bytes ⇒ inválido (equivale a limitar árboles a 128 hojas).
OP_SUCCESS* en tapscript (incluso no ejecutado) ⇒ inválido.
Ejecutar OP_IF / OP_NOTIF en tapscript ⇒ inválido.
Exención importante: inputs gastando UTXOs creados antes de la activación quedan exentos de las nuevas reglas.
4) Cómo se activaría (fase/plan de despliegue). El BIP define un despliegue “modified BIP9” con parámetros concretos:
- bit: 4
- threshold: 55% (1109/2016) en lugar de 95%
- max_activation_height: 965664 (~Sep 1, 2026)
- active_duration: 52416 bloques (~1 año)
Incluye una ventana de “mandatory signaling” (bloques no señalizadores serían inválidos durante un periodo específico).
También enlaza una implementación de referencia como comparación contra Bitcoin Knots (repo/branch).
5) ¿Quiénes lo apoyan y por qué? (argumentos “pro” documentados)
A) Autor y círculo “monetary-first”
El autor argumenta que la red está siendo usada para datos arbitrarios; que eso aumenta costos para nodos y compite con pagos; y que el softfork sería una señal fuerte de “no es un caso soportado”.
B) Referencia a Luke Dashjr
En los créditos del BIP: “Original draft and advice: Luke-Jr”.
6) ¿Quiénes lo critican y por qué? (argumentos “contra” documentados)
En el hilo de bitcoindev aparecen objeciones técnicas y de gobernanza:
A) Riesgo/precedente de “coerción” y marco legal/moral
Jameson Lopp critica implicaciones y la idea de empujar cumplimiento “legal/moral” como no-starter.
B) “No hace falta consenso”: alternativas por encoding / no-consenso.
Antoine Poinsot se alinea con esa línea (“zero need to change the consensus rules”) y sugiere enfoques alternativos (encoders/decoders).
C) Riesgo de “confiscación”/fondos congelados por transacciones pre-firmadas y tapscripts
En el mismo hilo se discute explícitamente el riesgo para presigned transactions y casos donde cambios de reglas pueden volver ciertos spends inválidos durante la ventana.
D) Tradeoff técnico: limita taptrees y puede afectar investigación. El BIP admite que limitar control blocks puede complicar o impedir casos avanzados y sugiere que “esperen a que expire” o usen testnet/sidechains.
7) “¿Cómo funcionaría” en Bitcoin (en práctica)?
Si se activara con ese mecanismo:
Los nodos/mineros que lo apliquen rechazarían bloques que incluyan transacciones con esos patrones (scripts/witness/taproot) durante la ventana activa.
Tras ~1 año (active_duration), las reglas dejarían de aplicarse automáticamente (el BIP mantiene estado ACTIVE pero condiciona enforcement por altura).
