Hace unos días, un desarrollador de Bitcoin Core publicó una propuesta de cambio para eliminar el límite de tamaño predeterminado de los datos en las salidas que utilizan OP_RETURN. Esto dio lugar a un debate entre desarrolladores y amplios sectores de la comunidad de Bitcoin, que por momentos se tornó acalorado y difícil de seguir. Aunque los mantenedores de Bitcoin Core parecen haber decidido seguir adelante con el cambio propuesto, otros critican la falta de consenso y las posibles consecuencias que esto podría tener en la red.
En este artículo, queremos tomar distancia del ruido y ofrecer un contexto útil sobre el concepto general de almacenar datos en la cadena de bloques de Bitcoin, es decir, datos que no están directamente relacionados con un pago real en Bitcoin. Exploraremos los distintos enfoques que se pueden adoptar para lograrlo, cómo funciona realmente OP_RETURN y de qué trata esta discusión más reciente. ¡Vamos allá!
Datos arbitrarios en la cadena de Bitcoin
La idea de almacenar datos en la cadena de bloques de Bitcoin es tan antigua como la propia red. Sin embargo, los debates sobre este tema se han intensificado en los últimos años, debido al creciente interés (y oposición) a guardar grandes cantidades de texto, imágenes o incluso videos en la cadena de bloques.
Discutir si un dato específico es “spam” o una “transacción económica” puede volverse rápidamente subjetivo e incluso un tanto filosófico. Por supuesto, hay muchas transacciones cuya justificación económica es claramente evidente, como un pago a la dirección de un comerciante reconocido o un retiro desde una billetera de un exchange. Algunos podrían referirse a estos pagos como “transacciones reales” de Bitcoin. Pero no siempre es tan sencillo. ¿Una transacción entre dos direcciones de tu propia billetera tiene relevancia económica? ¿Cómo sabemos si una dirección de Bitcoin es una “dirección real” y no algún mensaje oculto? ¿Acaso hay alguna diferencia?
Spam… ¡por todas partes!
El protocolo de Bitcoin ofrece muchos espacios donde las personas pueden almacenar datos que no son estrictamente transacciones. Por ejemplo, los mineros pueden usar la transacción coinbase para incluir un mensaje de texto, siendo el ejemplo más conocido el de Satoshi Nakamoto en el bloque génesis:
> The Times 03/Jan/2009 Chancellor on brink of second bailout for bank
Otros pueden (mal)utilizar las claves públicas y las direcciones como medio para almacenar datos. Normalmente, asumirías que una clave pública proviene realmente de una clave privada que alguien controla. Pero ¿cómo lo sabrías? Nada impide que alguien codifique un mensaje de texto en un conjunto de claves públicas y les envíe una pequeña cantidad de bitcoin. De hecho, esto es exactamente lo que han estado haciendo los usuarios del protocolo STAMP, saturando permanentemente el conjunto de salidas no gastadas (set de UTXO) de Bitcoin con salidas que probablemente nunca podrán ser gastadas.

Pero aún no hemos terminado: el protocolo Ordinals, que se hizo popular en 2023, utiliza la sección “witness” de los bloques de Bitcoin —donde normalmente se encuentran las firmas digitales— para almacenar grandes cantidades de datos. Incluso existe un incentivo para usar esta parte del bloque, debido a un descuento efectivo en las comisiones gracias a la forma en que se calcula el espacio de almacenamiento en las transacciones tipo SegWit. Por ejemplo, el bloque 774628 alcanzó casi los 4 MB de tamaño, y contenía una sola imagen en alta resolución de Julian Assange.

Rápidamente se hace evidente que, si quieres almacenar datos arbitrarios en la cadena de bloques de Bitcoin, definitivamente puedes hacerlo. Existen varias formas de lograrlo, y el único límite práctico es el tamaño máximo de bloque de 4 MB. ¡Y hasta ahora ni siquiera hemos mencionado las salidas OP_RETURN!
¿Una verdad incómoda ?
La mayoría de los campos en las transacciones y bloques de Bitcoin que no están directamente restringidos por reglas del protocolo pueden ser llenados con datos arbitrarios, sin relación con su propósito original. Esta es una circunstancia inevitable, ya que determinar si ciertos datos son relevantes requiere una interpretación subjetiva, lo cual no siempre es posible, especialmente en una red descentralizada y no regulada como Bitcoin.

Puedes estar de acuerdo o no con la idea general de almacenar datos arbitrarios en la cadena de bloques de Bitcoin —y eso está bien—. Sin embargo, dado que es prácticamente imposible evitarlo, se puede argumentar que existen formas mejores (y peores) de almacenar “spam” en la cadena de bloques de Bitcoin. Veamos más de cerca.
OP_RETURN
A pesar de su nombre, que puede parecer complicado, OP_RETURN es, sin duda, una de las funciones del lenguaje de scripts de Bitcoin más fáciles de entender… porque, en esencia, no hace nada. Cuando un nodo de Bitcoin verifica una transacción y encuentra una salida OP_RETURN, simplemente la trata como no gastable y continúa con la verificación.
A primera vista, esta “función” puede parecer inútil, pero existen dos razones principales para usar salidas con OP_RETURN:
- Quemar monedas: Los bitcoin enviados a una salida OP_RETURN quedan bloqueados para siempre y no se pueden gastar. Es una forma comprobable de “quemar monedas”, lo cual puede ser útil ocasionalmente por motivos legales… o simplemente por diversión si perdiste una apuesta. Por esta razón, debes tener mucho cuidado de no bloquear tus monedas por accidente al crear transacciones con OP_RETURN.
- Marcar datos como irrelevante: Cuando se trata de almacenar datos arbitrarios, OP_RETURN funciona como un indicador temprano que le dice a los nodos de Bitcoin que validan transacciones: “Puedes ignorar con seguridad lo que viene a continuación”. Como esta salida siempre será inválida para gastar, no hay motivo para conservar su contenido. Esto es ideal para los nodos que no desean almacenar toda la cadena de bloques de Bitcoin, conocidos como nodos podados (pruned nodes). Estos nodos pueden ignorar y eliminar con seguridad las salidas OP_RETURN junto con otros datos no necesarios, ahorrando espacio en disco y memoria.
¿Recuerdas cuando mencionamos lo difícil que puede ser, desde el punto de vista técnico, determinar si un dato es “irrelevante” o no? OP_RETURN les da a los usuarios la capacidad de tomar esa decisión por sí mismos y comunicarla a la red. Esto se puede considerar algo positivo, ya que es una solución más eficiente que algunas de las alternativas mencionadas anteriormente. Aunque las salidas OP_RETURN siguen contribuyendo al tamaño total de la cadena de bloques de Bitcoin, no se agregan al set de UTXO, lo que significa que los nodos no necesitan hacer seguimiento constante de ellas.

Políticas de la Mempool policies
Pero, ¿qué pasa con ese “límite” de OP_RETURN que se mencionó al principio?
Bitcoin Core incluye varios ajustes predeterminados y opciones de configuración que influyen en el comportamiento del nodo dentro de la red. Algunas de estas opciones determinan si el nodo debe retransmitir y almacenar una nueva transacción en su mempool local; a estas se les conoce comúnmente como políticas de mempool o reglas de estándar. Lo más importante es que determinar si una transacción es válida y puede incluirse en un nuevo bloque es un tema completamente distinto, regulado por las reglas de consenso, que no están relacionadas con esta discusión.
Al momento de escribir este artículo, Bitcoin Core establece por defecto un límite de 80 bytes de datos en las salidas OP_RETURN. Este límite puede modificarse en cualquier momento mediante una simple opción de configuración. Esto significa que un nodo no retransmitirá una transacción con una salida OP_RETURN que contenga más de 80 bytes de datos (o más, si así lo configura el usuario), y tampoco la añadirá a su mempool de transacciones no confirmadas. Sin embargo, si esa transacción es incluida en un nuevo bloque, el nodo igualmente la aceptará, ya que ese límite no es una regla de consenso.
En resumen, actualmente es bastante difícil difundir transacciones con salidas OP_RETURN grandes, ya que casi todos los nodos se niegan a retransmitirlas debido al límite predeterminado de 80 bytes. No obstante, esta limitación también tiene sus límites, lo cual es importante tener en cuenta para lo que viene a continuación…
- No es una regla de consenso: Las transacciones con salidas OP_RETURN más grandes son válidas según las reglas de consenso, por lo que los mineros pueden incluirlas voluntariamente. De hecho, una sola transacción podría incluir multiples salidas OP_RETURN con tamaños arbitrarios. Esto se puede lograr contactando directamente a los mineros o conectándose a nodos que no apliquen esta política, facilitando así la propagación de la transacción hacia los mineros. Cabe destacar que los mineros generalmente tienen un incentivo económico para incluir transacciones con altas comisiones, sin importar su contenido o contexto. Solo se necesita que un minero esté dispuesto a hacerlo.
- Métodos alternativos: Existen otros métodos para almacenar grandes cantidades de datos que son aún más difíciles de evitar, como las inscripciones en los datos de witness o el uso de claves públicas y hashes en salidas estándar, como mencionamos antes. El mal uso de salidas estándar para ocultar datos arbitrarios es, desde el punto de vista técnico, casi imposible de prevenir, y puede desencadenar fácilmente un juego del gato y el ratón: más reglas provocan métodos aún más sofisticados para ocultar datos.
Eliminando el límite
El principal argumento para eliminar el límite actual de 80 bytes es su ineficacia real para impedir el almacenamiento de datos en la blockchain, como lo demuestran alternativas igual de efectivas pero aún peores. Otra opción sería simplemente aumentar el límite, pero los mismos argumentos y limitaciones aplicarían también a cualquier límite superior, por lo que los desarrolladores de Bitcoin Core proponen eliminarlo por completo.
Restringir activamente el uso de salidas OP_RETURN también fomenta activamente el uso de métodos alternativos de almacenamiento, lo que genera incentivos contraproducentes. Mejorar la usabilidad de OP_RETURN, en cambio, mejora los requerimientos de recursos para los operadores de nodos y la eficiencia general de la red. Hace más de una década, las notas de lanzamiento de Bitcoin Core ya contenían esta misma justificación:
Este cambio no es un apoyo al almacenamiento de datos en la blockchain. El cambio en OP_RETURN crea una salida que puede ser eliminada de forma comprobable, para evitar esquemas de almacenamiento de datos —algunos ya implementados— que almacenaban datos arbitrarios como imágenes en salidas imposibles de gastar, inflando la base de datos de UTXO de Bitcoin.
Ahora que entendemos un poco mejor el razonamiento detrás de la propuesta de cambio, ¡también podemos echar un vistazo al otro lado del argumento!
¿Entonces, qué podría estar en contra del cambio propuesto
Aunque los defensores del cambio enfatizan la eficiencia y el pragmatismo técnico, el debate en torno a OP_RETURN ha sacado a la luz una serie de contraargumentos que van más allá de los detalles de implementación. Los críticos plantean preocupaciones tanto filosóficas como prácticas, cuestionando si el cambio se alinea con los objetivos a largo plazo de Bitcoin y si realmente aborda las fuentes principales del spam de datos en la cadena.
Una red financiera ante todo
La mayoría de los críticos quieren priorizar la preservación de Bitcoin como un protocolo financiero y evitar su uso como una capa de datos de propósito general. Desde esta perspectiva, eliminar el límite de OP_RETURN corre el riesgo de normalizar los usos no financieros y enviar una señal equivocada sobre para qué sirve la blockchain. Incluso si no representa un daño técnico, argumentan que levantar el límite podría atraer nuevos casos de uso que diluyan aún más el propósito original de Bitcoin y aumenten con el tiempo la presión sobre los operadores de nodos. Los escépticos también se preguntan si este cambio realmente reduciría de forma significativa el impacto negativo del spam en la red en general.
¿Por qué eliminar la posibilidad?
Algunos sostienen que eliminar el límite predeterminado es aceptable, pero eliminar por completo la opción de establecer un límite personalizado no lo es. Dado que ya existe una solución funcional para que los usuarios establezcan una limitación personalizada en las salidas OP_RETURN, se puede argumentar que no hay razón para eliminar esta posibilidad para quienes aún deseen usarla. Al fin y al cabo, las políticas de la mempool son algo que cada quien puede configurar por su cuenta, siguiendo el mantra de “tu nodo, tus reglas”.
Preocupaciones sobre el proceso
La manera en que se introdujo esta propuesta también ha generado críticas. La rapidez con la que se planea fusionar la pull request en la próxima versión de Bitcoin Core, combinada con la eliminación de opciones de configuración relacionadas para los usuarios, ha despertado inquietudes sobre una discusión insuficiente. Aunque el cambio no modifica las reglas de consenso, los opositores argumentan que alterar configuraciones predeterminadas de larga data sin un acuerdo amplio socava la confianza y sienta un precedente riesgoso.
Si no se ha roto, no lo arregles
Para muchos, esto se reduce, en última instancia, a una cuestión de prudencia. El cambio aborda un problema que tal vez no resuelve, conlleva posibles efectos secundarios y carece de un consenso claro. En estos casos, sostienen los críticos, el camino responsable es mantener la política actual, conservar abiertas las opciones y volver a tratar el tema solo con una justificación más sólida, soluciones diferentes o un respaldo más amplio. En un sistema como Bitcoin, donde la estabilidad y la previsibilidad son fundamentales, mantener el statu quo a veces es la decisión menos arriesgada y más sensata.
Prevención del spam
En general, la red de Bitcoin cuenta con un mecanismo muy importante para defenderse del spam: un mercado libre de comisiones por transacción. Con un suministro constante de espacio en los bloques —alrededor de 2-3 MB cada diez minutos—, la demanda de transacciones regula automáticamente su prioridad, sin necesidad de tomadores de decisiones centrales. Así como la oferta y la demanda determinan el precio cambiante del bitcoin, el mercado de tarifas asigna un precio a las transacciones. De esta manera, ninguna entidad debería poder manipularlo durante mucho tiempo, ya que nadie puede disponer de una cantidad infinita de bitcoin para pagar por ello.
Conclusión
Como ocurre con muchas discusiones en Bitcoin, no hay una respuesta claramente correcta o incorrecta, solo distintos compromisos. Si bien el cambio propuesto puede mejorar técnicamente la forma en que se maneja la información arbitraria, también plantea preocupaciones válidas sobre los incentivos a largo plazo, la dirección cultural y el propio proceso de toma de decisiones. Ya sea visto como una mejora práctica o como un precedente arriesgado, el debate refleja la complejidad de mantener un sistema descentralizado con prioridades diversas.
Imagina un futuro en el que una gran parte del mundo genere transacciones de Bitcoin con regularidad. Grandes corporaciones e incluso Estados podrían necesitar mover sus monedas. Los usuarios particulares tal vez tengan que crear y cerrar canales de Lightning frecuentemente. En resumen, si la demanda de transacciones es muy alta, las tarifas por transacción también lo serán. Podrías argumentar que es bastante improbable que, a largo plazo, haya un mercado significativo para datos “inútiles” en la cadena de bloques de Bitcoin. Así como es el mercado quien decide si Bitcoin tiene valor, es el mercado de tarifas quien decide si las transacciones tienen valor.
Considerando este principio fundamental, la decisión de limitar —o no— el tamaño de las salidas OP_RETURN quizá no tenga tanto impacto como podría parecer a primera vista. Lo que principalmente busca la eliminación del límite es una forma más eficiente de manejar cantidades mayores de datos arbitrarios. O, dicho de otro modo, elegir “el mal menor” en comparación con el mal uso de salidas estándar para almacenar datos.
También sirve como un gran ejemplo de cómo los debates sobre el desarrollo de Bitcoin pueden evolucionar e incluso dar lugar a una mayor diversidad en las distintas implementaciones de nodos, así como a una mayor conciencia sobre cómo funcionan realmente las políticas y las reglas de consenso. Pase lo que pase, todos podrán elegir y configurar el software de su nodo como deseen, porque eso es, en última instancia, de lo que trata Bitcoin.
¿Aún no tienes una BitBox?
Mantener tus criptomonedas seguras no tiene por qué ser difícil. La billetera física BitBox02 almacena las claves privadas de tus criptomonedas offline. Así podrás gestionar tus monedas de forma segura.
La BitBox02 también viene en versión sólo Bitcoin, con un firmware radicalmente enfocado: menos código significa menos superficie de ataque, lo que mejora aún más tu seguridad cuando sólo almacenas Bitcoin.
¡Hazte con una en nuestra tienda!

Shift Crypto es una empresa privada con sede en Zurich, Suiza. Nuestro equipo de colaboradores de Bitcoin, expertos en criptomonedas e ingenieros de seguridad crea productos que permiten a los clientes disfrutar de un viaje sin estrés desde el nivel de principiante hasta el nivel de maestría en la gestión de criptomonedas. La BitBox02, nuestra billetera de hardware de segunda generación, permite a los usuarios almacenar, proteger y realizar transacciones con Bitcoin y otras criptomonedas con facilidad, junto con su software complementario, la BitBoxApp.