Escrito por: Brandon Black
Compilado por: AididiaoJP, Foresight News
En el pequeño círculo de Crypto Twitter, se ha generado un acalorado debate durante el último año sobre la propuesta de "soft fork de reducción de datos temporales" (BIP110) presentada por @dathon_ohm.
La lógica central de esta propuesta es: ciertas transacciones de Bitcoin pueden insertar datos en sus scripts de bloqueo o desbloqueo que, además de su significado en el propio script de Bitcoin, pueden ser interpretados por otro software como información adicional. Esto es visto por sus proponentes como una violación de los principios de la red.
Ellos argumentan que reducir este tipo de transacciones es suficiente para justificar el soft fork de Bitcoin más "expropiatorio" hasta la fecha: su despliegue sería mucho más rápido que los dos últimos soft forks, y su umbral de activación, más bajo.
Bitcoin es esencialmente un libro mayor distribuido, de acceso abierto y resistente a la censura. Cualquiera que esté dispuesto a pagar una tarifa suficiente para convencer a los constructores de plantillas de bloques y a los mineros de incluir su transacción, puede escribir en este libro mayor. El valor fundamental de Bitcoin, que lo distingue de todos los demás sistemas de contabilidad, radica precisamente en esta apertura. Sin ella, el libro mayor de Bitcoin no sería muy diferente del marcador de una bolera. Debido a este acceso abierto, todos sabemos que Bitcoin será utilizado por personas que no nos gustan.
Es como el principio de la libertad de expresión: si solo protege el discurso que nos gusta, no tiene sentido. Lo mismo ocurre con el acceso abierto de Bitcoin: si solo permite las transacciones que tú o yo aprobamos, pierde su significado. Por lo tanto, no tenemos necesidad de censurar cómo otros construyen sus entradas en el libro mayor, así como no queremos que otros censuren las nuestras.
Los defensores del BIP110 podrían decir: "¡Por supuesto, pero esto es solo para entradas no monetarias! ¿Y las transacciones puramente monetarias?" La realidad es que no existe una distinción tan clara. Cada transacción en Bitcoin crea un registro en el libro mayor al cumplir las condiciones de un script de bloqueo: consume UTXOs de entrada y genera nuevos UTXOs de salida.
Que el script de una transacción sea un poco más grande o pequeño no importa en absoluto para los operadores de nodos o los usuarios comunes. En primer lugar, a mí no me importan en lo más mínimo los detalles de las transacciones de otros, es tan relevante como lo que otros piden en una cafetería. En segundo lugar, el propio nodo de Bitcoin no hace tal distinción. Una transacción solo es válida o inválida, con costos de verificación más altos o más bajos (por ejemplo, las transacciones multisig grandes son costosas de verificar, mientras que ciertos Ordinals o OP_RETURN son relativamente baratos).
Algunos argumentarían que Bitcoin sería un mejor activo monetario si, como el oro, no pudiera ser utilizado de "otras maneras". Imagina si el oro no pudiera usarse para joyería o fines industriales, quizás sería un dinero más puro. Pero son precisamente las propiedades físicas que hacen del oro un buen dinero, las que también lo hacen popular en joyería e industria.
Lo mismo ocurre con Bitcoin: precisamente porque permite que cualquiera pague para escribir datos, no podemos controlar cómo otros interpretarán esos datos. No importa cuánto restrinjamos la estructura de los scripts, siempre habrá quien utilice software externo a Bitcoin para interpretar esas entradas de otras maneras. Por lo tanto, como con el oro, debemos aceptar que los "otros usos" son inevitables. En el mercado del oro, esto conduce a distorsiones de precios por la fluctuación de la demanda no monetaria; en Bitcoin, puede provocar un aumento en las tarifas cuando la demanda de espacio de bloques se dispara.
Sin embargo, Bitcoin tiene dos ventajas sobre el oro. Primero, crear transacciones de Bitcoin que puedan ser interpretadas alternativamente no afecta directamente el mercado de Bitcoin como activo, a diferencia del oro; la cantidad de Bitcoin utilizada para estos "usos adicionales" es en realidad muy pequeña. Segundo, el protocolo de Bitcoin fue diseñado desde el principio con mecanismos para minimizar la carga que estos "análisis adicionales" imponen a la red de verificación. Limita el tamaño de los bloques y la cantidad de firmas (sigops) en las transacciones, que son precisamente las partes más costosas de verificar para un nodo.
Estas limitaciones, establecidas desde el principio, existen precisamente para prevenir el abuso de alto volumen y alta frecuencia del libro mayor. Son estas limitaciones las que han impulsado innovaciones de segunda capa como la Lightning Network, Ark, Spark, Cashu, etc. Incluso un aumento en la demanda de espacio de bloques por datos "no monetarios" promueve el uso de estos esquemas de escalamiento más eficientes, que registran menos contenido en la cadena principal.
Ahora que el supuesto razonamiento del BIP110 ha sido expuesto (y claramente es insostenible), veamos qué pretende cambiar realmente.
El BIP110 limitaría el tamaño de los scripts de bloqueo, limitaría la cantidad de scripts alternativos disponibles en Taproot, invalidaría los anexos (annex) de Taproot, eliminaría todas las versiones de testigo y Tapscript actualizables, eliminaría todos los opcodes actualizables en Tapscript, y deshabilitaría OP_IF y OP_NOTIF en Tapscript. Estas restricciones solo se aplicarían a los UTXOs creados durante aproximadamente 52414 bloques (alrededor de un año) después de la activación.
Además, el BIP110 reduciría el umbral de señalización de preparación de los mineros al 55% (los soft forks anteriores generalmente requerían más del 90%) e implementaría un mecanismo de activación forzada por nodos: si la señalización es insuficiente antes del bloque 961632, los nodos que ejecuten esta regla tratarán los bloques sin señal como inválidos, forzando así el bloqueo del cambio en el bloque 963648 y su activación en el bloque 965664.
Esta sería la restricción más radical al scripting de Bitcoin desde que Satoshi deshabilitó múltiples opcodes en 2010 debido a una grave vulnerabilidad (CVE-2010-5137). Pretende impulsar este cambio con un umbral de activación sin precedentes, un tiempo de activación extremadamente corto (menos de 9 meses desde la numeración del BIP hasta la activación) y una revisión de código mínima, todo bajo el pretexto de que hay personas interpretando las entradas del libro mayor de una manera que a los proponentes no les gusta.
Lo más irónico es que quienes utilizan los datos "objetados" ya han actualizado su software y están preparados: incluso si el BIP110 se activa, podrán seguir incrustando datos similares. Muchos de nosotros predijimos esto de antemano, porque en un libro mayor público y de acceso abierto, es imposible restringir cómo los usuarios interpretan las entradas con software externo.
En resumen, el BIP110 intenta hacer algo imposible: restringir cómo los usuarios utilizan un libro mayor de acceso abierto, mientras que el problema que dice resolver ya está bien manejado por las limitaciones existentes del protocolo de Bitcoin. Además, intenta imponerse de manera irresponsable con un calendario apresurado, una revisión de código precipitada y sin considerar el consenso del ecosistema. Afortunadamente, Bitcoin no es un sistema tan frágil, y este intento imprudente de modificación no tendrá éxito.
Los mineros ya han rechazado claramente el BIP110, y desarrolladores, inversores, KOLs y el mundo empresarial también han expresado su oposición. Para agosto de este año, este "ataque" a las reglas de consenso de Bitcoin terminará en fracaso, y Bitcoin saldrá fortalecido, continuando con su ritmo estable de generación de bloques, uno tras otro.
