-
Carvalho cuestionó los argumentos técnicos de Core para eliminar el límite en OP_RETURN.
-
La versión 30 de Bitcoin Core amplió el límite del opcode OP_RETURN de 80 bytes a 100 KB.
El matemático y desarrollador web Melvin Carvalho compartió un reporte en el que acusa a integrantes del cliente Bitcoin Core de manipulación discursiva (gaslighting, en inglés) y censura en el debate sobre la eliminación del límite de datos del opcode OP_RETURN.
El matemático fundamenta su mención al gaslighting en que desde Core mantuvieron comportamientos como «repetir hasta que sea cierto», «apelación a la autoridad» y «censurar la disidencia», así como también presentar como “resuelto” un tema con amplia oposición.
En la versión 30 de Core, se amplió el límite de 80 bytes a 100 KB para adjuntar datos en transacciones mediante el opcode OP_RETURN, una instrucción que inserta información arbitraria (como texto o referencias) en las transacciones, lo que generó malestar en parte de la comunidad.
En su informe, Carvalho afirma que el cambio se presentó como un simple ajuste de política de retransmisión en la política de nodos de Core, cuando, en su visión, modifica la función económica de Bitcoin al incentivar el almacenamiento de datos. En ese sentido, como lo reportó CriptoNoticias, a fines de octubre pasado, casi el 40% de las transacciones no movían valor monetario.
Adicionalmente, el desarrollador web sostiene que la ampliación no contó con «consenso aproximado», ya que en el repositorio oficial se registraron 423 posturas en contra frente a 105 a favor, una relación cercana a 4:1.
Asimismo, Carvalho resaltó el crecimiento de la adopción del cliente Bitcoin Knots y que “la respuesta de la comunidad” fue la creación de BIP-110, una propuesta de bifurcación suave para reducir el almacenamiento de datos en Bitcoin.
Los argumentos a favor de ampliar OP_RETURN y las réplicas de Carvalho
Carvalho señala que desarrolladores como Pieter Wuille y Peter Todd sostienen que el límite de OP_RETURN era irrelevante porque podía eludirse mediante datos en el campo testigo, esquemas multifirma o envío directo a mineros, lo que volvería ineficaz la política de retransmisión; sin embargo, replica que si el filtro reducía la visibilidad de esas transacciones en el mempool (donde esperan confirmación) entonces sí tenía efecto práctico y no era meramente simbólico.
También rebate la idea de que ampliar OP_RETURN sea el “mal menor” frente a la contaminación del conjunto de salidas no gastadas (UTXO), la base de datos que cada nodo mantiene para validar pagos.
A su juicio, no se trata de elegir entre «OP_RETURN ilimitado» o «contaminación del UTXO», sino de mantener límites y corregir abusos puntuales, ya que pasar de 40-80 bytes a 100 kilobytes transforma el opcode de ancla de datos a «una autopista de datos».
En cuanto al riesgo de centralización, Carvalho cuestiona que el filtro histórico haya generado ventajas privadas para mineros y sostiene que no hubo evidencia clara de ese efecto en más de una década.
Por el contrario, advierte que facilitar grandes volúmenes de datos podría atraer actores con capital suficiente para negociar infraestructura directa con mineros, reforzando dinámicas concentradas.
Respecto a la gobernanza, subraya que, aunque la política de retransmisión de los nodos no forma parte del consenso (las reglas que validan bloques), los valores predeterminados del cliente Core influyen en la mayoría de los nodos, ya que actualmente este software es operado por más del 77% del total de los nodos, por lo que cambiar el comportamiento por defecto altera de facto el flujo de transacciones, según Carvalho.
Finalmente, Carvalho alude a que desarrolladores como Zhao, Adam Back, Antoine Poinsot apelan a la neutralidad: el software no debería juzgar qué transacciones son legítimas según su contenido.
El matemático responde que Bitcoin siempre ha aplicado reglas de estandarización para proteger la red, por lo que eliminar un límite específico no es neutralidad absoluta, sino una decisión sobre qué usos se incentivan y quién asume sus costos.
