Bitcoin Core: Desarrolladores en el punto de mira tras duras críticas

Un preocupante cambio de filosofía está en marcha entre los desarrolladores de Bitcoin Core.

No_Return

Bitcoin Core está nuevamente bajo fuego crítico. El desarrollador francés Antoine Poinsot lanzó una bomba al proponer eliminar el límite respecto a la cantidad de datos arbitrarios (spam) que pueden ser insertados «legalmente» en las transacciones.

He aquí en esencia su propuesta (versión truncada) que detalla con más profundidad en su blog:

Por defecto, Bitcoin Core solo propaga y mina transacciones que contienen como máximo un OP_RETURN que no exceda los 83 bytes. […] Sin embargo, algunos logran evadir este límite. Por lo tanto, propongo eliminarlo para dejar de alentar técnicas de inserción de datos más dañinas […].

Antoine Poinsot

Comencemos explicando qué es «OP_RETURN«. Es un opcode que permite insertar limpiamente datos arbitrarios en una transacción. Este método «oficial» ofrece un espacio limitado de 83 bytes para ello.

Las transacciones que usan el opcode OP_RETURN tienen la particularidad de que generan UTxO que ya no pueden ser gastados (unspendable output). Usar OP_RETURN sirve para avisar a los nodos que no necesitan memorizar el UTxO de la transacción en cuestión.

[UTxO es el nombre que llevan los pequeños fragmentos de código (los «scripts») que vinculan matemáticamente los bitcoins a direcciones BTC (las direcciones son codificaciones de claves públicas).]

El vaso se desbordó cuando el desarrollador Peter Todd propuso eliminar de plano la posibilidad que tienen los nodos de configurar ellos mismos el límite de OP_RETURN:

Eliminemos también la opción de configuración -datacarriersize […]. Este límite es de todas formas fácilmente evadido mediante envíos directos a las mempools de los mineros (por ejemplo, MARA Slipstream) o ciertas técnicas de inserción.

Peter Todd

Vamos a explicarlo todo, no se preocupen.

Datos no gratos

¿De qué hablamos exactamente? ¿Qué son esos «datos arbitrarios» que generan tanto debate?

Comúnmente se les llama «inscripciones». Las más conocidas son los «ordinals». Generalmente son imágenes jpeg que se alojan dentro de los scripts de transacciones (P2TR). También están los STAMPS, aún más dañinos. Estos almacenan datos en forma de falsas claves públicas y generan grandes cantidades de UTxO (Baremultisig).

Estas inscripciones tienen en común que evaden OP_RETURN para escapar de sus límites, lo cual no está exento de consecuencias. Mientras que el conjunto de UTxO pesaba solo 4 GB antes de la moda de las inscripciones, hoy en día ya son 12 GB. La mitad de los UTxO contienen menos de 1000 sats, es decir, spam.

Este crecimiento amenaza la descentralización porque se vuelve más caro instalar un nodo (memoria, RAM, IBD, etc). Otro inconveniente es que interfiere con el uso legítimo de la red, que es realizar transacciones monetarias.

Aclaramos ahora la expresión -datacarriersize. Es el nombre del parámetro de configuración que define el límite de OP_RETURN. Por defecto, este límite está establecido en 83 bytes en las versiones recientes de Bitcoin Core.

Peter Todd se refiere aquí a lo que se llaman «policy rules» (reglas de política). Estas reglas permiten filtrar transacciones para evitar que se propaguen hasta las mempools de los mineros para ser añadidas a un bloque. El objetivo es impedir algunos ataques de denegación de servicio (DoS). Por ejemplo, Bitcoin Core no propaga transacciones que pesen más de 100,000 voctets.

[El mempool (contracción de «memory pool») contiene las transacciones válidas a la espera de ser incluidas en un bloque. Cada nodo tiene su propio mempool y sus propias configuraciones de filtro.]

Ahora que las bases están claras, entremos en el meollo del asunto. Hace dos años que el desarrollador Luke Dashjr recomienda filtrar las transacciones que contienen inscripciones.

El problema es que el pequeño concilio de desarrolladores que lidera Bitcoin Core se niega a hacerlo.

Saber limitar los daños

Bitcoin Core ha justificado su pasividad argumentando que los filtros que vayan en contra de los intereses financieros de los mineros acabarán siendo evadidos. De hecho, esto ya se ha dado con el sistema «slipstream» del minero Marathon.

Slipstream permite evadir los nodos de la red enviando las transacciones (que de otro modo serían filtradas) directamente a la mempool de Marathon.

Cierto, pero este servicio no es gratuito. Cuanto más caras sean las inscripciones de producir, menos habrá. Todo suma para limitar los daños. Sin mencionar que Marathon mina menos del 5 % de los bloques.

Es muy sencillo, solo 30 transacciones OP_RETURN de 7 millones han superado el límite de 83 bytes desde principios de año. Esto representa una tasa de éxito del 99,9957 % para el filtro anti-spam limitado a 83 bytes.

Volviendo a Peter Todd. Su propuesta molesta porque parece una capitulación ante la industria del spam. Más aún, porque levantar los límites de OP_RETURN muy probablemente no tendrá ningún impacto positivo respecto al spam.

¿Por qué? Por la sencilla razón de que las nuevas técnicas de inserción son cuatro veces más baratas que con OP_RETURN debido a que aprovechan el «witness».

Este enorme descuento está relacionado con el soft fork SegWit, que hizo pasar el tamaño de los bloques de 1 MB a 1 vMB. La «v» significa «virtual».

Segwit, el origen del mal

SegWit es el fruto de un compromiso surgido de la «Blocksize war», un episodio que vale la pena explorar. Para ser claro, SegWit permitió aumentar el tamaño de los bloques de 1 MB a 4 MB.

Esto se debe a que las transacciones SegWit están divididas en dos secciones diferentes. Los bytes de la primera sección se cuentan como si pesaran 4 Vbytes, mientras que los bytes de la sección witness pesan un solo Vbyte.

Así, un bloque que contiene 1 MB de transacciones clásicas (sin SegWit) pesa 4 VMB. Un bloque de 4 MB con una sola transacción que lleva una imagen de 4 MB en el witness pesa 4 VMB.

El problema es que nadie podía predecir (aunque en realidad sí…) que el witness sería explotado por spammers. Los creadores de SegWit pensaban que la sección witness solo contendría firmas ECDSA legítimas y que los bloques alcanzarían un máximo de 1,5 a 2 MB.

Hoy la mayoría del spam se aloja en el witness de scripts de transacciones P2TR. Estos scripts no están destinados a ser ejecutados: sirven únicamente como almacenamiento para datos arbitrarios (imágenes, textos, JSON, etc.), hasta 4 MB por bloque.

¿A quién beneficia el delito?

Una posible respuesta es que los filtros retrasan la propagación de bloques que contienen OP_RETURN que exceden el límite de 83 bytes. Por lo tanto, el minero Marathon tiene un interés financiero en que se elimine ese límite.

El proyecto Citrea de Jameson Lopp también se beneficiaría. El cypherpunk fue de hecho uno de los primeros en apoyar la propuesta de Peter Todd. A este respecto, cabe señalar que Bitcoin Mechanic (CTO del pool Ocean) fue baneado de Github Bitcoin por señalar este conflicto de intereses. Irónica censura…

Terminemos subrayando que Bitcoin es un sistema de pagos. Facilitar otros usos dañinos para la descentralización de la red es una píldora difícil de tragar. Ante el diálogo de sordos que se ha instalado con Bitcoin Core, cada vez más personas migran a otras implementaciones como Bitcoin Knots.

Bitcoin Knots es una versión modificada de Bitcoin Core mantenida por Luke Dashjr. Es un cliente alternativo para la red Bitcoin. Ofrece funcionalidades adicionales y correcciones de bugs que los desarrolladores de Core se niegan a implementar.

El siguiente paso consiste en cortar los fondos a organizaciones como @OpenSats, @bitcoinbrink, @HRF, así como retirar fondos de los ETF que patrocinan desarrolladores dictadores. Esperemos que la controversia sea suficiente para convencer a Bitcoin Core de no hacer nada.

Aquí para quienes hablan inglés, una larga diatriba de Bitcoin Mechanic para entender bien la situación:

Si aún estás aquí, seguramente apreciarás este artículo sobre Bitcoin y la Amenaza Cuántica.