Dos forks nuevos de Bitcoin, cero relación entre ellos: esto es lo único que tienes que hacer

Si tienes Bitcoin en autocustodia y solo quieres saber qué hacer: nada, salvo que decidas moverte activamente hacia una de las dos cadenas nuevas que han aparecido desde agosto de 2026. Tu Bitcoin real sigue en la cadena con más del 99% del hashrate, exactamente igual que antes. El riesgo real no es perder acceso a él por la existencia de estos forks, es confundir una cadena con otra al usar una wallet mal configurada.

Desde agosto de 2026 coexisten dos cadenas nuevas derivadas de Bitcoin, y casi todo lo que circula sobre ellas las mezcla en una sola conversación de gobernanza. No lo son. Nacieron de motivaciones distintas, las llevan equipos distintos, y no comparten ni calendario ni argumento. Este artículo las separa con los datos verificados hasta hoy y responde a la única pregunta operativa que importa.

Las dos cadenas, en una tabla

(Cifras a 5 de septiembre de 2026. El estado de ambas cadenas cambia con cada bloque, comprueba siempre la fuente antes de actuar.)

Antecedente rápido: por qué existe BLAKE2b

El BIP se dio oficialmente por cerrado. Luke Dashjr perdió los permisos de editor del repositorio de BIPs y anunció una excedencia en Ocean. Start9 retiró el paquete RDTS de su distribución normal. Con la propuesta original ya muerta, un grupo liderado por Roughnecks reactivó la cadena el 10 de agosto con una build "Knots-RDTS" y, para poder minar con la potencia real que sí tenían disponible en lugar de competir con la dificultad heredada de toda la red, cambiaron el algoritmo de minado. El nuevo algoritmo, BLAKE2b, se eligió el 11 de agosto mediante un proceso aleatorio determinista sobre bloques de Testnet4, pensado explícitamente para que nadie pudiera preminar con antelación. El primer bloque bajo las reglas nuevas es el 961.640, el 30 de agosto de 2026, y la cadena acumula ya más de 800 bloques. BLAKE2b favorece CPU y GPU sobre los ASIC de SHA-256, así que anula de un plumazo la ventaja de hardware que tenía el resto de la red.

eCash (ECX): un proyecto sin ninguna relación con el anterior

eCash es harina de otro costal por completo. Lo impulsa Paul Sztorc, fundador de LayerTwo Labs y autor de BIP-300 y BIP-301, las dos propuestas de drivechains que llevaba años sin conseguir que Bitcoin adoptara. En lugar de tocar el algoritmo de minado, eCash mantiene SHA-256 (la misma prueba de trabajo que Bitcoin de siempre) y bifurca con un simple reseteo puntual de la dificultad al mínimo, activando drivechains desde el primer bloque.

El despliegue va por fases marcadas por altura de bloque, no por fecha de calendario: la fase alfa arrancó el 23 de agosto en el bloque 963.648, la beta llega el 20 de septiembre en el 967.680, y la activación permanente está fijada para el 31 de octubre en el bloque 973.728, coincidiendo con el 18º aniversario del whitepaper de Bitcoin. Durante alfa y beta se reparte pECX, monedas de práctica sin valor definitivo (1 pECX por cada BTC en el momento del snapshot correspondiente) que se queman y se canjean por ECX real después del 31 de octubre. La tracción durante la fase alfa fue real y verificable: más de 25.000 bloques minados en unas 13 horas, con un hashrate de 3,53 PH/s, y la ventaja de que cualquier minero de SHA-256 (hasta un Antminer S9 ya jubilado del resto de la red) puede participar sin comprar hardware nuevo.

El punto más polémico es de reparto, no técnico: parte de los aproximadamente 1,1 millones de BTC que suelen atribuirse a Satoshi Nakamoto quedaría fuera del reparto uno-a-uno y pasaría a inversores tempranos y al propio desarrollo del proyecto [VERIFICAR: la cifra exacta de esa proporción varía según la fuente consultada; compruébala en la documentación oficial de eCash antes de citarla como definitiva]. Sztorc lo niega tajantemente: "no tocamos ningún bitcoin de Satoshi, los saldos de BTC quedan intactos con eCash". Sea cual sea tu lectura, es un debate sobre cómo se reparte una moneda nueva, no sobre si tu Bitcoin actual está en riesgo.

Qué le pasa a tu nodo de Bitcoin: nada

Si operas un nodo de Bitcoin (Core o cualquier implementación estándar) y no tocas ninguna configuración, no le pasa absolutamente nada. Sigue validando la misma cadena que ya validaba, con la misma prueba de trabajo SHA-256d de siempre, sin ninguna acción de tu parte. Ninguna de las dos cadenas nuevas puede cambiar eso: BLAKE2b se separó por un cambio de reglas que tu nodo, corriendo software estándar, rechaza automáticamente por diseño (igual que rechazó la señalización de BIP-110 en su momento), y eCash es una cadena hermana con su propio génesis efectivo, no una modificación de la que ya sigues.

La única forma de que tu nodo se vea implicado en cualquiera de las dos es que tú decidas activamente instalar un cliente distinto o apuntar tu wallet a un servidor de esas redes. Nada de lo que hagan Roughnecks o LayerTwo Labs se propaga hacia atrás a tu instalación estándar.

El riesgo real: confundir una cadena con la otra

Aquí está el motivo por el que este artículo merece existir, y no es la gobernanza. BLAKE2b y eCash comparten con Bitcoin el bloque génesis, el nombre de red y el formato de direcciones. Eso significa que si tu wallet se conecta al servidor equivocado, no vas a ver ningún mensaje de error: vas a ver un saldo, transacciones, y una cadena que sincroniza con total normalidad, salvo que no es la que tú elegiste.

El caso concreto que lo demuestra son las notas de una build de Sparrow (versión 2.5.4, publicada el 31 de agosto por el desarrollador conocido como paulscode) construida específicamente para seguir la cadena BLAKE2b. Sus propias notas de publicación explican el problema con precisión técnica: como las dos cadenas mainnet comparten génesis, network magic y formato de direcciones, una wallet conectada al servidor equivocado sincroniza sin ningún fallo visible y muestra el saldo de una cadena que el usuario nunca eligió conectar. La solución de esa build en concreto es leer el punto de fork que reporta el propio servidor (en el campo server.features del protocolo) y rechazar cualquier servidor que discrepe del esperado o que no lo reporte en absoluto.

Si vas a tocar cualquiera de las dos cadenas nuevas, la pregunta que de verdad importa antes de conectar tu wallet no es "¿qué versión tengo?", es "¿cómo sé que este servidor concreto está en la cadena que creo que está?". Sin esa verificación explícita, el riesgo no es teórico.

Si decides indexar alguna de las dos: aislamiento de nodos

Tanto BLAKE2b como eCash conservan el network magic de Bitcoin y los puertos estándar 8333/8332, así que apuntar un nodo a cualquiera de las dos sin aislarlo bien puede terminar mezclando tráfico con la red principal. Tres medidas mínimas, no opcionales:

• Datadir dedicado: nunca compartas la carpeta de datos entre tu nodo de Bitcoin y un nodo de cualquiera de estos forks. Son bases de datos incompatibles disfrazadas de compatibles.
• Peers fijados a mano: no dejes que el descubrimiento automático de pares elija por ti. En una red minoritaria con network magic reutilizado, conectar con el peer equivocado te puede llevar a una cadena distinta de la que crees.
• Verificar el hash del bloque de fork: antes de confiar en cualquier sincronización, confirma que el hash del bloque de separación (961.632 para BLAKE2b, 963.648 para eCash) coincide exactamente con el que publican fuentes independientes, no solo con el que reporta tu propio nodo recién montado.

Si no vas a operar tú mismo un nodo de ninguna de las dos cadenas, esta sección no te afecta: es exclusivamente para quien decida indexarlas.

Qué hacer con los saldos: el orden de operaciones importa

Como las dos cadenas heredaron el historial completo de Bitcoin hasta su punto de separación, cualquier BTC que tuvieras en ese bloque existe también como saldo equivalente en la cadena nueva (en eCash, formalmente, tras la conversión de pECX a ECX el 31 de octubre). Esto no es urgente ni tiene fecha límite real, pero si decides acceder a ese saldo, el orden en que lo hagas es lo único que puede salir mal.

Primero, mueve tu Bitcoin real a una semilla completamente nueva y limpia. Solo después, con las llaves viejas ya vacías de tu Bitcoin de verdad, úsalas para tocar la cadena del fork que te interese. Nunca al revés. La protección de replay en BLAKE2b es opt-in vía una extensión de firma llamada SIGHASH_UNIFIED (una wallet que la implementa, como la build de Sparrow ya mencionada, marca la operación como protegida de forma explícita), no un mecanismo universal: una firma que no active ese bit sigue siendo válida en ambas cadenas a la vez, y alguien podría retransmitirla donde no querías. En eCash, la protección también depende del software oficial y de que actives la separación de forma explícita, no es automática por el mero hecho de tener el saldo. Si tocas primero la cadena vieja y algo sale mal, arriesgas tu Bitcoin real; si tocas primero la nueva desde una semilla ya limpiada de fondos reales, el peor caso es perder un saldo que técnicamente nunca has gastado con normalidad.

Higiene: ninguna herramienta necesita tu semilla

Ninguna herramienta legítima para comprobar, reclamar o convertir un saldo en cualquiera de estas dos cadenas necesita que introduzcas tu frase semilla en ningún sitio. Nunca. No existe ninguna ventana de reclamación con fecha límite real para el saldo que ya tienes por el mero hecho de haber tenido Bitcoin antes del split: la sensación de urgencia ("hazlo antes de que expire", "solo unas horas más") es en sí misma la señal más fiable de que algo es una estafa, no una característica legítima de ninguno de los dos proyectos descritos aquí.

Si el tratamiento fiscal de estos saldos te preocupa, en España la fiscalidad de monedas surgidas de un fork no es trivial y depende de matices que no cubrimos aquí: consulta con un asesor fiscal antes de mover o vender nada, no asumas que el criterio de otra jurisdicción te aplica igual.

Nada de esto es una previsión sobre qué van a valer estas cadenas, ni una recomendación de comprar, vender o participar en ninguna. Puedes seguir el estado real de nuestro propio nodo (que sigue la cadena principal, con más del 99% del hashrate, sin ninguna acción de nuestra parte) en Red y minería, y leer el trasfondo completo del fallo de BIP-110 en nuestra cobertura anterior.

Última actualización: 5 de septiembre de 2026