¿Qué se está construyendo hoy en Bitcoin?

El precio de bitcoin (BTC) suele acaparar los titulares, pero el trabajo que sostiene al protocolo sigue su calendario propio. Ese trabajo queda registrado en el repositorio y en los foros donde los desarrolladores discuten cada cambio antes de que llegue a la red principal.

Una investigación de los repositorios oficiales de Bitcoin en GitHub, las solicitudes de incorporación de código (pull requests) abiertas, los hilos con mayor número de respuestas en Delving Bitcoin y la lista de correo bitcoindev, junto con los resúmenes semanales de Bitcoin Optech (especialmente los números 417 y 418 de agosto de 2026), permitió identificar las líneas de trabajo con mayor volumen de discusión técnica en las últimas semanas.

BIP-54 apunta a corregir fallas heredadas del consenso

La propuesta de mejora de Bitcoin 54 (BIP-54), conocida como Consensus Cleanup (limpieza de consenso) y escrita por Antoine Poinsot y Matt Corallo, corrige cuatro problemas técnicos puntuales del protocolo.

El conflicto más comentado ataca el llamado ataque timewarp, una técnica mediante la cual un atacante con la mayoría del poder de cómputo de la red puede manipular las marcas de tiempo de los bloques para engañar al algoritmo que ajusta la dificultad de minería, el parámetro que determina cuán difícil es encontrar un bloque válido y que la red recalcula cada 2.016 bloques para mantener un promedio de diez minutos entre cada uno.

Un primer arreglo a ese ataque dejó abierta una variante que el propio Poinsot detectó después junto al investigador pseudónimo Zawy, consistente en fijar las marcas de tiempo de dos períodos de dificultad muy lejos en el futuro para forzar una baja artificial. BIP-54 cierra esa variante, conocida como regla Murch-Zawy, exigiendo que el último bloque de un período de dificultad nunca tenga una marca de tiempo anterior a la del primero.

Los otros dos arreglos de la propuesta limitan la cantidad de operaciones de firma que puede contener una transacción heredada (legacy), para evitar los llamados «bloques veneno» que pueden tardar minutos u horas en validarse, e invalidan las transacciones de exactamente 64 bytes, que pueden confundirse con nodos internos del árbol de Merkle.

La especificación de BIP-54 ya se fusionó en el repositorio oficial de Bitcoin, lo que significa que su diseño técnico quedó cerrado, aunque todavía no está activada en la red principal de Bitcoin.

La discusión técnica de fondo ocurrió en un hilo de Delving Bitcoin, que retoma una propuesta original de Corallo de 2019 y acumula 92 respuestas, la de mayor cantidad en ese sitio.

En abril de 2026, Poinsot y el desarrollador Anthony Towns hicieron además una demostración pública en la red de pruebas Signet para mostrar en la práctica el segundo problema que ataca la propuesta: bloques válidos pero deliberadamente lentos de validar, apodados «bloques veneno».

La implementación completa de las cuatro reglas avanza en el repositorio oficial de Bitcoin a través de una pull request abierta el 24 de julio por el propio Poinsot. En paralelo, otras pull requests atacan piezas puntuales de esa misma implementación, como la que refuerza específicamente la regla Murch-Zawy dentro del código de minería, abierta el 11 de agosto por el desarrollador fjahr.

La lucha por los datos dentro de un bloque tiene dos candidatos

La discusión sobre qué tipo de datos deben poder guardarse dentro de un bloque de Bitcoin no es nueva. OP_RETURN es un código de operación que permite adjuntar datos arbitrarios dentro de una transacción —como texto, imágenes o archivos— sin que ese contenido sea procesado por la red como un envío monetario.

En octubre de 2025, Bitcoin Core, el software de referencia de la red, elevó el límite por defecto de ese campo de 83 a 100.000 bytes, lo que facilitó su uso para almacenar volúmenes mucho mayores de información no financiera. Ese cambio profundizó la disputa entre quienes defienden la neutralidad de Bitcoin frente a cualquier tipo de dato y quienes buscan reservar el espacio de bloque para uso estrictamente monetario, la misma discusión de fondo que derivó en la propuesta BIP-110 (que ya fue marcada como cerrada).

Sobre ese trasfondo, el desarrollador MrHash publicó el borrador Segregated Data (SegData), que acumula 47 respuestas en Delving Bitcoin y es una de las más activas en las últimas semanas.

SegData no toca el límite de OP_RETURN. En cambio, crea una región de bloque nueva, separada de los scripts que definen las condiciones de gasto de una transacción, pensada para alojar datos como los que hoy circulan a través de protocolos como Runes.

Esa región sería podable (prunable), es decir que esos datos podrían borrarse una vez validados por los nodos sin perder la capacidad de verificar el resto de la cadena, y quedaría comprometida mediante una referencia (commitment) incluida en la transacción coinbase, la primera de cada bloque, con la que el minero cobra la recompensa.

Sobre esa misma discusión, el desarrollador Pieter Wuille propuso el 25 de junio en la lista de correo de desarrolladores de Bitcoin un mecanismo que garantice la desactivación futura de la criptografía de curva elíptica en tipos de salida preparados para computadoras cuánticas.

Direcciones resistentes a la computación cuántica

BIP-360 es una de las propuestas técnicas que hoy avanza para blindar a Bitcoin ante la eventual llegada de una computadora cuántica con potencia suficiente para romper la criptografía que protege las claves de la red. Tanto en Bitcoindev como en Delving Bitcoin, es uno de los debates más activos con decenas de hilos en ambos foros.

La propuesta define un nuevo tipo de dirección llamado Pago a Raíz de Merkle (P2MR), que se basa en el formato Taproot (el más moderno de Bitcoin y que permite construir condiciones de gasto más complejas), aunque P2MR elimina la vía de gasto que expone la clave pública en esas direcciones Taproot. Así, BIP-360 evita que un atacante cuántico futuro pueda usar esa clave visible para derivar la clave privada y acceder a los fondos de usuarios.

BIP-360 se incorporó al repositorio oficial de propuestas de Bitcoin el 11 de febrero de 2026 y todavía no tiene fecha de activación, como ya lo explicó CriptoNoticias.

¿Qué discuten los desarrolladores en Bitcoin Optech?

Los resúmenes semanales de Bitcoin Optech de las primeras semanas de agosto de 2026 muestran que los desarrolladores siguen empujando otras mejoras, de menor perfil pero igual de constantes.

Una de las más comentadas es un nuevo mensaje de red llamado Stale Tip Relay, para que los nodos avisen cuando un bloque válido queda fuera de la cadena principal, algo hoy difícil de rastrear porque ese bloque deja de propagarse en cuanto gana la cadena competidora. Contar con esa señal ayudaría a detectar antes problemas de propagación o comportamientos anómalos en la red.

También avanza CISA, que combina en una sola firma las distintas entradas (inputs) de una misma transacción y así reduce el tamaño de las operaciones que gastan varias entradas a la vez.

En paralelo, Bitcoin Core se prepara para su versión 32.0, con cambios que vuelven más eficiente el uso de recursos de los nodos. Uno de ellos reemplaza el límite de transacciones retransmitidas por conexión individual por un límite global, para que un pico de actividad no sature de golpe la CPU o la memoria del equipo.

A eso se suma la actualización de la biblioteca criptográfica libsecp256k1 a su versión 0.8.0, que sumó soporte nativo para los pagos silenciosos (Silent Payments) y mejoras de velocidad en la verificación de firmas.

Todo esto se discute abiertamente en los mismos foros y repositorios que cualquiera puede consultar. En conjunto, el panorama que muestran los números 417 y 418 de Optech es el de un desarrollo constante y sin grandes saltos espectaculares, pero con avances prácticos en rendimiento, privacidad y resiliencia de la red.