Bitcoin Core libera OP_RETURN y con ello todos ganamos

Adiós a los 80 bytes: Bitcoin Core libera OP_RETURN para datos sin límites

La comunidad de Bitcoin vive un momento crucial con la reciente eliminación del límite para el código de operación OP_RETURN en Bitcoin Core. Esta decisión da fin al debate intenso y apasionado entre los desarrolladores y usuarios de la red, liderado en gran parte por figuras como Peter Todd. Recordemos que OP_RETURN, una función crucial dentro del lenguaje de scripting de Bitcoin, permite insertar datos arbitrarios en la blockchain, pero hasta hace poco estaba restringida a un límite muy estricto de 80 bytes por transacción. Pero con la eliminación de este límite, abre un nuevo panorama lleno de posibilidades para el desarrollo, la privacidad y la innovación dentro de Bitcoin.

Al mismo tiempo, la inclusión de los cambios, es un duro golpe para desarrolladores como Luke Dashjr y Bitcoin Mechanic, quienes se habían posicionado en contra de la medida. Incluso llamaban a boicotear el desarrollo de Core y abandonar el proyecto, para migrar a Bitcoin Knots, un proyecto que está bajo el absoluto control de Luke Dashjr. En todo caso, la medida de los devs representa un hito significativo para Bitcoin, su modelo UTXO y el futuro del desarrollo de protocolos complementarios como Runes, BRC-20, BitVM, RGB, ZK Rollups sobre Bitcoin y más. Quédate con nosotros y conocerás el enorme impacto que esta medida tendrá en la mayor criptomoneda del mundo.

PECTRA DESBLOQUEARÁ EL USO REAL DE LOS $490.000 MILLONES QUE PROTEGE ETHEREUM

Eliminación del límite OP_RETURN en Bitcoin Core

Hasta abril de 2025, Bitcoin Core imponía una restricción en el uso del código OP_RETURN, limitando la cantidad de datos incrustados a apenas 80 bytes, y permitiendo solo una salida de este tipo por transacción. Esta limitación tenía la intención de preservar la función monetaria principal de Bitcoin y evitar la saturación de la cadena con datos no relacionados con transacciones financieras. La medida fue puesta en marcha en Bitcoin Core 0.9.0 (2014), un momento cuando la red Bitcoin apenas está creciendo y fortaleciéndose. En ese entonces, la idea de limitar OP_RETURN tenía como objetivo evitar que la red creciera de forma descontrolada, que se frenará la expansión de la misma y que esto lastrará la evolución de Bitcoin.

Pero mucho ha llovido desde entonces. Bitcoin pasó por momentos alcistas enormes, la red ha crecido en tamaño, y el uso de la red también ha evolucionado. Tenemos Lightning Network, se están desarrollando protocolos como Taro, BitVM (RGB) e incluso ZK Rollups sobre Bitcoin. También tenemos Layer 2 adicionales como Stark o RSK, o proyecto tan explosivos como Runes o BRC-20. Ciertamente, no estamos en 2014 y muchos desarrolladores de Bitcon han entendido eso.

Una propuesta inicia todo

Aquí es donde nace la propuesta para eliminar esta limitación (que nuevamente, fue puesta en 2014, antes de eso, la limitación era más laxa). Frente a la medida está Peter Todd, uno de los desarrolladores más versados de Bitcoin. Participo en desarrollos como Mastercoin, RBF, Lightning Network, OpenTimestamps, SegWit, Covenants para Bitcoin, e incluso en proyectos como ZCash. Bajo el PR #32359, Todd propone eliminar la limitación de OP_RETURN junto a las opciones de control de Bitcoin Core (datacarrier y datacarriersize).

¿Razones? Todd afirma (y está en lo correcto), que estos límites no tienen sentido, ya que son evadidos por otros medios en servicios como MARA Slipstream o versiones modificadas de Bitcoin Core que ignoran tales restricciones. Pero no solo eso, sino que esa limitación sobre OP_RETURN, lleva a usar espacios no prunables (que no se pueden eliminar) que insertan datos innecesarios en el conjunto UTXO (salidas de Bitcoin, que no son prunables), complicando la validación y el rendimiento de los nodos completos que sostienen la descentralización de la red. En su lógica, Todd avisa que es preferible deslimitar OP_RETURN para que los usuarios puedan usar este espacio para incluir datos arbitrarios, el lugar de usar espacio UTXO como pasa actualmente (ej: las Runes usan espacio UTXO dentro del almacenamiento SegWit de las transacciones de Bitcoin, algo que no se puede deshacer).

Propuesta innovadora, pero con matices

Lo mejor es que la eliminación de dicho límite no afecta las reglas de consenso, permitiendo a cada nodo decidir la política que desea adoptar (si, quien no desee los datos OP_RETURN, puede hacer un prune de los mismos y borrarlos de su nodo), fortaleciendo así la naturaleza descentralizada de Bitcoin. La flexibilidad aportada por esta medida posibilita el registro directo en la blockchain de datos mucho más extensos y múltiples salidas OP_RETURN por transacción.

ETORO RECONOCE RIESGOS REGULATORIOS POR PRIVACIDAD DE DATOS EN EUROPA Y REINO UNIDO

Como ven, la propuesta de Todd está bien fundamentada. Usar el espacio UTXO para cosas como Runes es una locura, y usar el espacio por OP_RETURN tiene más sentido. Si no te gusta Runes, no hay problema, lo puedes prunear y borrar ese contenido, sin alterar la parte crypto del proceso (cosas como el hash de la TX o el hash del bloque, quedan intactos). Pero si no te importa y deseas apoyar a Bitcoin con toda la comunidad que está dentro del mismo, pues dejas el nodo como viene por defecto y no hay problemas.

Creatividad

Esto es positivo por qué al final, esta eliminación del límite no deja a los usuarios de nodos completos sin opciones para decidir sobre esos datos. Al mismo tiempo, los usuarios de Runes u otros protocolos que hagan uso de OP_RETURN, podrán hacerlo sin chocar con una limitación para su creatividad. Puedes que sus creaciones tengan un aspecto financiero. Por ejemplo, Citrea y sus ZK Rollups buscan crear un Bitcoin más privado y con smarts contracts para usarse en DeFi. O pueden que tengan un uso de privacidad, donde por ejemplo las ECDH Address podrían brillar aún más, dándole a los usuarios de Bitcoin la capacidad de tener direcciones stealth, altamente privadas e integradas enteramente en el protocolo, gracias a que OP_RETURN sin límites, nos abre la puerta para ello. Como ves, hay muchas cosas positivas en esto.

El lado negativo

Sin embargo, todo tiene su mala cara. Luke Dashjr y Bitcoin Mechanic expresaron serias preocupaciones en ese sentido, porque esto podría representar un riesgo para la red, al facilitar un incremento excesivo en el almacenamiento de datos arbitrarios, poniendo en peligro la eficiencia de nodos completos y la descentralización. Dashjr, en particular, justificó su postura con el efecto nocivo que la acumulación de grandes cantidades de datos puede tener en el peso y operatividad de la cadena. Y esto es cierto, pero olvidan que para eso hay contrapesos, empezando que las OP_RETURN se pueden prunear una vez estén validadas sus transacciones, o el hecho, de que con OP_RETURN sin límites se acaba el incentivo de usar SegWit y se obliga a estas personas a pagar comisiones sin descuento dentro de la red.

Después de todo, el principal filtro ante el spam es el fee market (mercado de comisiones), ya que recordemos a medida que la mempool de Bitcoin se llena, más cara se hacen las comisiones. Con esta medida, obligar a usar OP_RETURN, significaría que cualquier persona que genere un Runes, tendrá que pagar comisiones completas, en lugar de beneficiarse por el espacio SegWit. Y finalmente, los mineros son más felices con ello, ya que este posible aumento (por uso excesivo de OP_RETURN para almacenar datos) significa mejores ganancias para ellos.

Como se ve es una medida centrada, con sus puntos buenos y malos, pero una medida que le da a todos oportunidades, y no se centra solo en censurar, que es lo no deseado.

SAMOURAI WALLET, EL JUICIO QUE DEFINIRÁ LA PRIVACIDAD EN BITCOIN

Futuro de Bitcoin con OP_RETURN liberado

En todo caso, la inclusión de este nuevo código para deslimitar OP_RETURN todavía está esperando las últimas revisiones. Pero, mirando hacia el futuro, la eliminación del límite en OP_RETURN abre un abanico de posibilidades para Bitcoin. Aclarando que esto no significa que no haya nuevos desafíos más adelante, pero esto es un buen paso para un proyecto como Bitcoin, que es visto en la comunidad FOSS como muy estático.

De hecho, discusiones como si aceptar la activación de OP_CAT  y OP_CTV, llevan años estancadas en los «Que pasa si» de muchos desarrolladores, enviando un mensaje de «temor a cambiar y hacer evolucionar Bitcoin». Un mensaje que se ha hecho cada vez más presente en Bitcoin desde su último fork con la activación de Taproot, el cual llevó años en hacerse una realidad. Cuando la realidad nos lo ha dejado claro, cambiar es parte de todo y el hacerlo no significa renunciar a tus orígenes. Casey Roadmor inicio una revolución en Bitcoin lanzando Ordinals, y para hacerlo no cambio Bitcoin, solo lo adapto, y con un poco más de ayuda, podría explotar aún más sus posibilidades.

Ese mismo espíritu, de evolucionar e ir adelante, lo vimos con Satoshi Nakamoto, quien lanzó un software de Bitcoin inicial que parecía más bien un juego, pero que junto a personas como sirius-m o Gavin Andressen se transformó en lo que es hoy en día. Quizá vaya siendo hora de que Bitcoin vaya tomando ritmo, quizás no tan acelerado y frenético, pero si uno que le permite ir avanzando y adaptándose al futuro.

Comparte esto: