BIP-110 explicado: que revela un soft fork polemico sobre el consenso de Bitcoin

La pregunta bajo el fork

BIP-110 es facil de archivar bajo la larga disputa sobre los Ordinals y los datos arbitrarios en Bitcoin. Ese encuadre pierde lo que de verdad esta en juego. La propuesta no anade un filtro local que cada operador de nodo pueda elegir. Cambia las reglas de consenso que deciden que bloques pertenecen a Bitcoin.

Es un tipo de cambio distinto. Un filtro antispam es una preferencia. Una regla de consenso es una definicion. BIP-110 plantea una pregunta que esta por encima del debate sobre los datos: debe Bitcoin solo comprobar si una transaccion es valida bajo reglas neutras, o deben las reglas prohibir ademas ciertos usos del espacio en los bloques? Y de la primera se deriva una segunda: hasta donde puede llegar una minoria para imponer su respuesta preferida?

Este es un analisis de esas preguntas y de la mecanica que las vuelve urgentes este mes. CanoeBit no toma posicion sobre el precio de Bitcoin y no ofrece ninguna recomendacion sobre lo que nadie deberia hacer. Para la situacion actual, el calendario de activacion y el error reportado en el cliente, consulta la noticia BIP-110 cerca de la senalizacion obligatoria.

Que restringe realmente BIP-110

Durante alrededor de un ano, es decir 52.416 bloques, BIP-110 anadiria siete reglas de consenso. Los nuevos scripts de output se limitarian a 34 bytes, con los outputs OP_RETURN permitidos hasta 83. Los data push y los elementos witness usados como argumentos de script se limitarian a 256 bytes. Las versiones de witness y Tapleaf no definidas no podrian gastarse, el annex de Taproot quedaria prohibido, los control block se limitarian a 257 bytes, y OP_SUCCESS ademas de las instrucciones OP_IF y OP_NOTIF ejecutadas serian invalidas en Tapscript.

El matiz importante es que estas reglas son generales. Apuntan a las tecnicas en las que hoy se apoyan las inscription, pero inciden de forma amplia en Script, en los datos witness y en varias rutas de actualizacion de Taproot. La propia especificacion admite casos estrechos y experimentales que involucran transacciones Taproot prefirmadas, en los que los fondos podrian en teoria congelarse o perderse, aun poniendo gran cuidado en proteger con grandfathering cada moneda confirmada antes de la activacion.

Asi que la propuesta no es una limpia "prohibicion de los Ordinals". Es un endurecimiento amplio de como puede verse una transaccion Bitcoin valida, con un pequeno riesgo residual para usos legitimos pero no documentados. Es algo que vale la pena sopesar, no porque el riesgo sea grande, sino porque nadie puede enumerar cada construccion contractual que ya circula.

El steelman: por que la preocupacion es legitima

La frustracion detras de BIP-110 no es irrazonable, y vale la pena exponerla en su forma mas fuerte antes de desmontarla.

Los full node deben descargar y validar cada bloque. Los scripts de output no gastados viven en el UTXO set, que los nodos mantienen en memoria rapida y no pueden podar. Las grandes inscription compiten con las transacciones monetarias por el escaso espacio en los bloques, pueden elevar las comisiones para los pagos ordinarios, y parte del contenido incrustado es material que los operadores de nodo preferirian no alojar en absoluto. Si uno cree que el primer proposito de Bitcoin es ser dinero, ver su espacio en los bloques llenarse de datos que gravan para siempre a cada nodo es una queja autentica.

Ese argumento es coherente. El desacuerdo no va sobre si la incrustacion de datos tiene costes. Va sobre si un cambio de consenso temporal y de umbral bajo es el instrumento adecuado para afrontarlos.

Donde el razonamiento se adelgaza

Dos problemas debilitan la propuesta en sus propios terminos.

El primero es economico. El diseno original de Satoshi ya contiene un mecanismo antispam: las comisiones y un limite fijo al tamano del bloque. Cuando el espacio en los bloques se llena, se vuelve caro, y los usos que no aportan ningun retorno monetario tienden a quedar fuera de precio. No es teoria. Las oleadas de inscription se han enfriado repetidamente a medida que subian las comisiones y la actividad dejaba de pagarse sola. Una regla de consenso que solo hace mas dificil un metodo invita a los datos a desplazarse, no a desaparecer.

El segundo problema es peor, y es donde la cura podria alimentar la enfermedad. Si se prohibe el almacenamiento de datos contiguos en los campos evidentes, los actores decididos pueden repartir las cargas en muchos pequenos push o disfrazarlas como datos financieros normales. Distribuidos en muchos outputs, esos datos pueden acabar en el UTXO set, la unica parte de la cadena que los nodos no pueden podar. En el esfuerzo por dejar fuera los datos no deseados, el cambio arriesga trasladarlos al lugar mas caro para almacenarlos. La propuesta no lo niega. Sostiene que la fragmentacion y el mayor coste envian igualmente un mensaje. Es un punto real, pero es un mensaje, no una solucion.

Como se formaria una division de la cadena

La mecanica de la division es simple, y en parte por eso el riesgo es creible. Desde el bloque 961.632, los nodos BIP-110 y los nodos Bitcoin normales aplican reglas distintas. Si un bloque activa el bit 4, ambos lados pueden aceptarlo. Si un bloque no lo hace, los nodos normales lo siguen considerando valido, mientras que los nodos BIP-110 lo rechazan.

En ese momento los dos grupos dejan de seguir la misma cadena. Con la abrumadora mayoria del hashrate sin senalar, la cadena Bitcoin normal continuaria casi sin perturbaciones, mientras que los nodos BIP-110 esperarian a que uno de los pocos mineros que senalan produzca un bloque en su rama. Una segunda cadena puede existir en el plano tecnico. Si importa en el plano economico es una pregunta aparte, y los datos actuales no sugieren que fuera a importar.

Dos decisiones de diseno agudizan el peligro. No existe ninguna proteccion replay general, asi que una transaccion puede ser valida en ambas cadenas a la vez, un peligro que los forks anteriores han demostrado cuando los usuarios mueven sus monedas en las primeras horas. Y el propio cliente de activacion arrastra el error de actualizacion reproducible documentado en el informe BlockSlop, en el que dos nodos que ejecutan las mismas reglas pueden acabar en cadenas distintas segun el historial de su directorio de datos. Un cambio de consenso cuyo propio cliente no puede garantizar que nodos identicos coincidan no es maduro.

El numero que lo decide todo

El umbral de senalizacion es el centro silencioso de esta disputa. Taproot, una actualizacion no polemica y puramente aditiva, se desplego con un umbral de los mineros del 90 por ciento. BIP-110, que elimina capacidades existentes y puede desencadenar una division, fija su liston en el 55 por ciento.

Esa inversion es reveladora. El cambio de mayor riesgo pide menos acuerdo del que pedia el de menor riesgo. La defensa de la propuesta es que una regla temporal, de un ano, no necesita una disposicion casi universal. Leido en clave estructural, sin embargo, el umbral bajo parece menos un margen de seguridad y mas un intento de superar un liston que el apoyo amplio no logra alcanzar por si solo. Y ni siquiera el 55 por ciento esta cerca: la senalizacion se ha mantenido en pocos puntos porcentuales durante todo el despliegue.

Aqui la expresion "senalizacion obligatoria" invita a un malentendido. No obliga a los mineros a activar nada. Solo significa que los nodos BIP-110 rechazaran los bloques que no senalen a partir de esa altura. Si la mayoria de los mineros sigue produciendo bloques normales, esos bloques siguen siendo validos para el resto de la red, y son los nodos BIP-110 los que se quedan atras. Un soft fork activado por los usuarios puede presionar a los mineros, pero solo cuando una mayoria economica creible de exchanges, custodios, wallets y usuarios rechaza todo salvo la cadena mas estricta. Ninguna mayoria de ese tipo es visible para BIP-110.

Una cadena que iria a paso de tortuga

Supongamos que una cadena BIP-110 separada se forma y retiene el pequeno hashrate que ahora senala, alrededor del uno y medio por ciento de la red. Heredaria la dificultad actual de Bitcoin con una fraccion de la potencia necesaria para satisfacerla.

La aritmetica no perdona. Los bloques llegarian en promedio cada unas once horas en lugar de cada diez minutos, casi 68 veces mas despacio. Bitcoin reajusta la dificultad solo cada 2.016 bloques, y a ese ritmo alcanzar el primer ajuste llevaria del orden de 950 dias, unos dos anos y medio. Hasta entonces la cadena produciria bloques ocasionales, no una red de pagos funcional. Una cadena minoritaria es tecnicamente posible. Una utilizable, con estos numeros, no lo es.

La lectura de CanoeBit, y donde cae

Nuestra lectura estructural es esta: BIP-110 tiene muchas mas probabilidades de producir una cadena minoritaria pequena, lenta y en gran parte ignorada que de cambiar Bitcoin, y su diseno de activacion sustituye el consenso por la afirmacion. Repetir que una propuesta tiene consenso no lo crea. El consenso surge cuando usuarios, mineros, desarrolladores y empresas independientes convergen voluntariamente en unas reglas, y esa convergencia aqui no es visible.

Como un analisis honesto nombra sus propias condiciones de fracaso, aqui estan las nuestras. Esta lectura caeria si una parte significativa del hashrate migrara a la rama BIP-110, o si grandes exchanges, custodios y proveedores de wallets se comprometieran a tratar solo la cadena mas estricta como Bitcoin. En ese caso existiria una verdadera mayoria economica y el calculo cambiaria. Tambien caeria si las bajas cifras de senalizacion estuvieran mal medidas y la disposicion real fuera mucho mayor de lo que muestran los paneles. Ninguna de esas condiciones es evidente hoy, pero ambas son observables, y ambas son lo que observariamos para saber que nos equivocamos.

El punto mas acotado se mantiene sea cual sea el desenlace del fork. Vale la pena tener un debate sobre el espacio en los bloques y el almacenamiento de datos. Decidirlo con un cambio de consenso construido a las prisas y de umbral bajo, aplicado por un cliente con un error de divergencia conocido, es una mala manera de tenerlo.