Resumen
Bitcoin CVE-2023-50428 fue presentado por Luke Dashjr el 2023-12-09 contra Bitcoin Core hasta la versión 26.0. La entrada en NVD, con puntuación 5.3 MEDIUM y marcada como Disputed, afirma que el límite de política -datacarriersize puede eludirse envolviendo datos dentro de un envelope OP_FALSE OP_IF en el testigo de script-path de Taproot. Bitcoin Core lo calificó como una pregunta de política. No una ruptura de consenso. Nunca lanzó un parche. Bitcoin Core 30.0, publicado el 2025-10-10, elevó el límite predeterminado de -datacarriersize de 83 bytes a 100,000 bytes a través del PR #32359. Un aumento de 1,200x. Lo opuesto de lo que pedía el CVE. Bitcoin Knots implementó el filtro en 25.1.knots20231115 y creció de unos 69 nodos en enero de 2024 a aproximadamente 4,240 de 23,842 nodos accesibles en septiembre de 2025. Los fondos nunca estuvieron en riesgo. El consenso nunca se rompió. El episodio muestra cómo se ve la gobernanza de Bitcoin cuando una decisión del cliente de referencia y un filtro de un cliente alternativo coexisten en la misma red.
El CVE que Luke Dashjr presentó contra Bitcoin Core
Trabajo en el espacio de la auto-custodia cripto. He visto el debate sobre las inscripciones dividir salas llenas de desarrolladores de Bitcoin desde principios de 2023. Luke Dashjr presentó CVE-2023-50428 el 2023-12-09 contra Bitcoin Core hasta la versión 26.0. El argumento era simple. Las inscripciones incrustan contenido arbitrario en los datos testigo de una transacción usando un patrón de script que el filtro de política -datacarriersize existente ignora. Como mantenedor de Knots, Dashjr llamó a eso una vulnerabilidad. Los mantenedores de Core lo llamaron una decisión de política.
El registro en NVD tiene puntuación base CVSS v3.1 de 5.3 MEDIUM con vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. Ese vector importa. El impacto en Confidencialidad es Ninguno. El impacto en Integridad es Ninguno. Solo Disponibilidad muestra impacto Bajo. Sin fondos en riesgo. Sin claves en riesgo. Sin bloques inválidos. Solo la capacidad de retransmisión del nodo.
La línea de estado en NVD dice Disputed. Los mantenedores de Bitcoin Core revisaron el parche de filtro en el issue #29187 de bitcoin/bitcoin y rechazaron fusionarlo. Bitcoin Knots publicó su propio filtro en la versión 25.1.knots20231115 ese mismo mes.
Qué hace el mecanismo en realidad
Las transacciones de Bitcoin pueden llevar pequeñas cantidades de datos arbitrarios. La ruta clásica es OP_RETURN. La política de nodo -datacarriersize limitaba las cargas útiles de OP_RETURN a 83 bytes por defecto (80 bytes de carga útil más 3 bytes de overhead de opcodes). Ese límite siempre fue un filtro de política. Nunca una regla de consenso.
El CVE describe una ruta diferente. Dentro de un gasto de script-path de Taproot, el testigo puede contener scripts arbitrarios. Una inscripción envuelve su contenido en un envelope OP_FALSE OP_IF <data chunks> OP_ENDIF. El OP_FALSE garantiza que la rama condicional nunca se ejecute. Los datos se tratan como pushdata inerte en lugar de código ejecutable. El filtro -datacarriersize nunca inspeccionó esta ruta. El contenido de tamaño arbitrario pasaba sin restricciones.
Esto es un bypass de política. No una ruptura de consenso. Cada transacción de inscripción es una transacción de Bitcoin válida bajo las reglas de consenso. Los mineros las incluyen. Los nodos completos las aceptan. Lo único que eluden es un filtro en tiempo de retransmisión, y solo en nodos que se molestaron en aplicarlo.
Por qué Bitcoin Core lo llamó política y no consenso
La posición de Core se basó en dos observaciones técnicas y una observación de gobernanza.
Las observaciones técnicas eran directas. Las transacciones citadas son válidas bajo consenso. Los operadores de nodos pueden configurar sus propias políticas de retransmisión hoy mismo. Forzar al cliente de referencia a bloquear transacciones válidas globalmente sería una intervención mucho más pesada que las inscripciones en sí.
La observación de gobernanza era más difícil. Bitcoin Core no tiene mandato para ganar disputas sociales. Publica la implementación de referencia. Los operadores que no están de acuerdo pueden ejecutar clientes alternativos sin dividir el consenso. Bitcoin Knots existía precisamente para que los operadores que veían la retransmisión de inscripciones como dañina tuvieran una opción disponible.
Casey Rodarmor lanzó Ordinals en la red principal de Bitcoin el 2023-01-21. La inscripción #0 fue creada el 2022-12-14. Para cuando se presentó el CVE en diciembre de 2023, la técnica llevaba casi un año en uso activo en la red principal. El gato ya había salido de la bolsa.
Dos clientes divergieron
Bitcoin Core rechazó el parche de filtro. Las transacciones de inscripción siguieron siendo elegibles para retransmisión bajo la política predeterminada de Core.
Bitcoin Knots 25.1.knots20231115 publicó el filtro. El inspector de Knots lee el testigo en busca de un envelope OP_FALSE OP_IF y descarta la transacción en la retransmisión si la carga útil supera el límite configurado.
Ambos clientes aplican las mismas reglas de consenso. Ambos validan los mismos bloques. Difieren en qué transacciones retransmiten antes de la minería.
La adopción de Knots fue un barómetro de qué porcentaje de la red coincidía con la posición del filtro. Los nodos Knots accesibles pasaron de aproximadamente 69 en enero de 2024 a unos 4,240 de 23,842 nodos accesibles a principios de septiembre de 2025. Alrededor del 17.78 por ciento de la red escuchando. Ese pico vino junto con la disputa de política de v30.0, no con la presentación original del CVE.
Dos años después, Bitcoin Core elevó el límite 1200x
Bitcoin Core 30.0 se publicó el 2025-10-10. Una línea de política en las notas de versión reenmarcó todo el episodio.
El PR #32359 de Peter Todd elevó el -datacarriersize predeterminado de 83 bytes a 100,000 bytes. Un aumento de 1,200x. El mismo PR también eliminó el límite en la cantidad de salidas OP_RETURN por transacción. Los operadores que querían el comportamiento anterior podían seguir pasando -datacarriersize=83 al iniciar.
El encuadre importa. Dos años después de que un CVE pidiera a Core que restringiera el filtro de OP_RETURN, Core publicó una versión que efectivamente lo retiró. El razonamiento en el hilo del PR fue que la aplicación se había vuelto inviable en la práctica. Las inscripciones ya habían sorteado el límite a través de envelopes en el testigo. El límite de OP_RETURN estaba penalizando la única ruta diseñada explícitamente para pequeñas cantidades de metadatos arbitrarios mientras dejaba la ruta no intencionada completamente abierta. Los mantenedores enmarcaron el cambio como simetría. No como rendición.
Interprétalo como quieras. El resultado empírico es que el filtro de política que el CVE pedía a Core que extendiera ahora está configurado por defecto para ignorar más de cien kilobytes por transacción.
Bitcoin Knots siguió publicando su propio filtro más estricto en paralelo. La versión v30.0 fue lo que impulsó el pico de adopción de Knots en septiembre de 2025.
Qué muestra este episodio sobre la gobernanza de Bitcoin
Bitcoin no tiene CEO. No tiene junta directiva. No hay forma de imponer un parche de seguridad a una implementación de referencia. Para una mirada más profunda a cómo funciona el protocolo consulta el Análisis Técnico Detallado.
Lo que CVE-2023-50428 realmente puso a prueba fue si el proceso social alrededor de Bitcoin Core podía ser presionado por un CVE presentado formalmente. La respuesta fue no. El CVE se convirtió en un registro público. El parche no se convirtió en el predeterminado. Dos años de debate después, Core se movió en la dirección opuesta.
Ese resultado es el sistema funcionando como fue diseñado. No como roto. Un desarrollador que no estaba de acuerdo publicó un cliente diferente. Los operadores que coincidían con él ejecutaron ese cliente. La implementación de referencia estableció los valores predeterminados que coincidían con la realidad real en la cadena. La red siguió produciendo bloques durante todo el proceso. Ningún fondo estuvo en riesgo. Ningún consenso se rompió.
Si llegaste a este CVE buscando un incidente de seguridad, no hay ningún incidente que limpiar. Si llegaste buscando un hito de gobernanza, así es como luce uno en Bitcoin. Un desacuerdo presentado formalmente. Dos clientes. Una red que no requiere acuerdo unánime para seguir funcionando. Un valor predeterminado que eventualmente alcanza a la realidad.
Para higiene de cartera que se mantiene independientemente de las disputas de política de retransmisión, consulta la guía de auto-custodia de Bitcoin y la guía de fuerza bruta BIP-39.
Lecturas adicionales:
- CVE-2023-50428 Detalle en NVD
- Registro CVE-2023-50428 en cve.org
- Issue #29187 de bitcoin/bitcoin
- Notas de versión de Bitcoin Core 30.0
- release-notes-30.0.md en GitHub
- PR #32359 Eliminar límites arbitrarios en salidas OP_RETURN datacarrier
- Documentación del Protocolo Ordinals
¿Nuevo en Bitcoin? Empieza con el Capítulo 1. Son ocho minutos.
¿Quieres la imagen completa? Lee los 19 capítulos gratis o pide el libro físico.
