Tu Mejor Share Solo No Fue Bloque: eCash RTT

El Real-Time Targeting de eCash, conocido como Heartbeat, es una regla de consenso que eleva el objetivo de minado exigido durante unos dos minutos tras cada bloque, y luego lo deja decaer hasta la dificultad publicada. Un share que supera la dificultad mostrada en un explorador solo es un bloque válido si llega después de ese decaimiento. Esta es, con diferencia, la razón más común por la que un minero en solitario de XEC ve un share récord y no gana nada.

Conclusiones clave

• eCash exige una dificultad superior a la publicada durante unos 115 segundos tras cada bloque, con una cadencia estable.
• El requisito arranca astronómicamente alto y cae como la quinta potencia del tiempo transcurrido. Nunca puede ser más fácil que la dificultad estándar.
• Los exploradores muestran la dificultad de cada bloque tal como fue minado: el valor mínimo. No existe ningún feed público del requisito en vivo.
• Reprodujimos la fórmula oficial contra los propios logs de un nodo en producción a lo largo de 15 mediciones: desviación máxima del 0,002%.
• La pronunciada rampa inicial con la que se topan hoy los mineros en solitario existe enteramente por la actualización del 15 de noviembre de 2025, que añadió una ventana de filtro de un bloque.

¿Por qué mi share superó la dificultad de red y no encontró un bloque?

Un minero nos escribió con una queja precisa y totalmente razonable. Había resuelto un bloque de eCash con un share de aproximadamente 8,0 mil millones de dificultad frente a una dificultad de red publicada de unos 7,36 mil millones. Horas después su minero registró un share mucho mejor —unos 11,87 mil millones— y no pasó nada. Revisó todos los bloques de la cadena desde entonces. La dificultad publicada se había mantenido entre 7,1 y 7,4 mil millones toda la noche. Bajo las reglas de Bitcoin, ese share era un bloque.

Tenía razón en los números y estaba equivocado en la regla. En eCash, la dificultad que publica un explorador no es la dificultad que hay que superar en el momento de enviar. Es el suelo.

Su share de 11,87 mil millones llegó unos 100 segundos después del bloque anterior, todavía dentro de la rampa. En ese momento la red exigía 14,85 mil millones, así que el share valía en torno al 80% de lo necesario. Quince segundos más tarde la rampa se despejó, el requisito cayó a 7,33 mil millones, y ese mismo share habría ganado. No le faltó hashrate. Le faltó un cuarto de minuto.

¿Qué es el Real-Time Targeting de eCash?

El Real-Time Targeting se activó con la actualización Heartbeat el 15 de noviembre de 2024. El problema que resuelve es específico de las cadenas SHA-256 minoritarias.

eCash comparte algoritmo con Bitcoin y Bitcoin Cash, así que el hashrate se mueve entre ellas persiguiendo rentabilidad. Cuando la dificultad de eCash baja, entra hashrate externo en tromba y mina varios bloques en rápida sucesión: los bloques turbo. El algoritmo de dificultad estándar reacciona subiendo la dificultad; el hashrate visitante se marcha; la cadena queda varada con una dificultad alta y una fracción del hashrate, produciendo huecos entre bloques que pueden durar horas. Los depósitos se atascan. Las confirmaciones se vuelven impredecibles.

Heartbeat ataca la primera mitad de ese ciclo. Al invalidar los bloques minados demasiado pronto tras su predecesor, elimina el incentivo de la minería en ráfagas, de modo que el algoritmo base nunca llega a sobrecorregir. El diseño está inspirado en la investigación sobre Real-Time Block Rate Targeting de Tom Harding.

El mecanismo solo funciona gracias a Avalanche. El objetivo en tiempo real depende de la medición propia de cada nodo sobre cuándo llegó un bloque, algo intrínsecamente subjetivo. El post-consenso de Avalanche reconcilia esas visiones subjetivas en una única decisión de red, sin tocar la cabecera del bloque ni el consenso Nakamoto.

¿Cómo se calcula el objetivo en tiempo real de eCash?

La regla está implementada en Bitcoin ABC como una política de aparcamiento en vez de como una regla de validez. El código relevante vive en src/policy/block/rtt.cpp, y la fórmula central aparece en el propio comentario del archivo:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K vale 6, así que el objetivo escala con la quinta potencia del tiempo transcurrido. T es el espaciado objetivo para esa ventana de filtro. El tiempo transcurrido se mide desde que el nodo recibió cada cabecera de bloque anterior, no desde la marca temporal escrita en la cabecera.

La fórmula se evalúa sobre cinco ventanas simultáneamente, y gana el resultado más estricto:

Las longitudes de ventana son números primos saltándose uno entre entradas sucesivas. El código fuente explica por qué: es un intento a conciencia de evitar frecuencias resonantes al encadenar una serie de filtros. La serie se detiene en 17 bloques porque más ventanas ya no cambian la selectividad del filtro de forma significativa.

Dos propiedades importan al minero. Se aplica el objetivo más bajo de todas las ventanas, así que gobierna la restricción más dura. Y el resultado está acotado: el objetivo en tiempo real nunca es más alto —nunca más fácil— que el objetivo estándar. La dificultad solo puede empujarse hacia arriba, nunca hacia abajo.

Reconstruir las constantes a partir de gamma(1 + 1/6) = 0.9277193336 reproduce los cinco coeficientes publicados con diez cifras significativas.

¿Cuánto más difícil es un bloque de eCash justo después del anterior?

Esta es la tabla que no existe en ningún otro sitio, calculada con la fórmula oficial a una cadencia estable de diez minutos. El multiplicador se aplica a la dificultad que publicaría un explorador.

Un bloque encontrado un segundo después de su predecesor necesitaría en torno a veinte mil millones de veces la dificultad publicada. A los diez segundos, doscientas mil veces. La curva es brutalmente empinada y luego simplemente se detiene: tras unos 115 segundos el requisito iguala exactamente a la dificultad publicada, y ahí se queda.

Cuando los bloques recientes llegaron más rápido de diez minutos, todas las ventanas parten de un tiempo transcurrido más corto y la rampa arranca más alta y dura más. Eso no es un efecto secundario. Es el mecanismo anti-bloques-turbo haciendo su trabajo.

¿Coincide la fórmula con lo que hace realmente un nodo?

Lo comprobamos. Abajo están los valores registrados por uno de nuestros nodos de eCash en los dos minutos y medio posteriores a un bloque, junto a los valores que predice la fórmula publicada usando únicamente los tiempos de llegada de bloque visibles en ese mismo log.

En las quince mediciones registradas la desviación máxima fue del 0,002%. La fórmula publicada no es una aproximación de lo que hacen los nodos: es exactamente lo que hacen.

Merece la pena destacar un detalle. Durante los primeros 99 segundos la restricción vinculante fue la ventana de un bloque. Solo a los 109 segundos tomó el relevo la ventana de dos bloques, y 40 segundos más tarde la dificultad estándar marcó el suelo.

¿Qué cambió el 15 de noviembre de 2025?

Antes de esa actualización había cuatro ventanas, empezando en dos bloques. La actualización del 15 de noviembre de 2025 añadió la ventana de un bloque con su espaciado de 150 segundos.

Pasar ambas configuraciones por la fórmula a una cadencia estable de diez minutos produce un resultado llamativo:

A una cadencia normal, la configuración de cuatro ventanas no producía ninguna rampa en absoluto. Solo entraba en juego cuando los bloques ya estaban llegando demasiado rápido, que era su propósito acotado. La empinada rampa inicial con la que se topa hoy un minero en solitario, en una cadena por lo demás sana, existe enteramente por la ventana de un bloque añadida en noviembre de 2025.

Si minaste eCash en solitario antes de esa fecha y nunca viste que ocurriera esto, ahí tienes el motivo.

¿Por qué la dificultad que muestra mi pool no coincide con la del explorador?

Porque en eCash son números distintos, y el software de minería lo dice.

El software de minería en solitario para eCash de Bitcoin ABC lee rtt.nexttarget en cada llamada a getblocktemplate, lo convierte a dificultad y —solo para eCash— usa ese valor como la dificultad de red que reporta y registra. Cualquier otra cadena SHA-256 usa en su lugar los bits de dificultad de la cabecera del bloque.

Esa única bifurcación explica el comportamiento que ve todo operador de pool de eCash: tras llegar un bloque, la dificultad de red reportada es astronómicamente alta, cae un orden de magnitud cada diez segundos durante unos dos minutos, y luego se aplana en el valor que un explorador acabará publicando.

Los operadores de nodo tienen una segunda opción: calcular el objetivo localmente a partir de rtt.prevheadertime, rtt.prevbits y rtt.nodetime, todos presentes en la plantilla de bloque. Ambas rutas están documentadas en la página de minería de eCash.

¿Qué le ocurre a un bloque que viola el objetivo en tiempo real?

Queda aparcado, no rechazado. El nodo lo marca con una violación de política etiquetada policy-bad-rtt y lo aparta, y después el sondeo de Avalanche decide si el resto de la red está de acuerdo. Si el nodo queda en minoría, cambia su postura. La cabecera del bloque permanece intacta en todo momento, y el consenso Nakamoto no se modifica.

Ejecutar getchaintips en un nodo de eCash muestra estos junto a la cadena activa, marcados como status: parked. En uno de nuestros nodos la llamada devolvió 262 puntas de rama aparcadas entre las alturas de bloque 940.265 y 960.666 —unos 20.400 bloques—, así que alrededor del 1,3% de los bloques de ese rango estuvieron aparcados al menos una vez.

Esa cifra es una cota superior de las violaciones del objetivo en tiempo real, no un recuento de ellas. eCash aparca bloques por varios motivos, y Avalanche también aparca el bando perdedor de una carrera de bifurcación ordinaria. Pero en una cadena donde dos bloques competidores a la misma altura son raros, una tasa de puntas aparcadas por encima del uno por ciento te dice que el mecanismo está activo y trabajando, no parado.

¿Se aplica esto a Bitcoin, Bitcoin Cash o las demás cadenas SHA-256?

No. Entre las cadenas SHA-256 este comportamiento es exclusivo de eCash, porque depende de la capa Avalanche para reconciliar la temporización subjetiva.

En Bitcoin y Bitcoin Cash, un share por encima de la dificultad de red es un bloque, y punto. Si minas varias cadenas y estás comparando tus cifras de mejor share entre ellas, la columna de eCash es la única donde la temporización entra en el cálculo. Nuestro desglose de probabilidades de minería en solitario y el Radar de Red usan ambos la dificultad publicada, que es la base correcta para la probabilidad a largo plazo: la rampa se promedia con el tiempo.

¿Cómo de grande es la zona muerta para un minero en solitario?

Todo share que caiga antes de que la rampa se despeje se desperdicia, por bueno que sea. A una cadencia estable:

Aproximadamente una quinta parte de cada intervalo de bloque es inutilizable para un share que apenas supera la dificultad. Los shares más fuertes despejan la rampa antes, que es la razón por la que un share verdaderamente enorme casi nunca se desperdicia.

Esto no cambia tu retorno esperado de ninguna forma sobre la que puedas actuar. Ya está reflejado en la producción real de bloques de la cadena, y por tanto en la propia dificultad. Nada en la configuración de tu minero influye en ello.

¿Qué debería hacer realmente un minero en solitario al respecto?

Para la mayoría, la respuesta honesta es nada, pero lee bien tus números.

• La pantalla de mejor dificultad de tu minero se calcula localmente, en el instante en que se encuentra el hash, antes de que el pool haya respondido. Registra el valor tanto si el share iba a ser válido como si no. Además es una cifra histórica que no se reinicia cuando encuentras un bloque.
• Un mejor share histórico por encima de la dificultad publicada en eCash no es prueba de un bloque perdido o robado. Si quieres confirmar que existe un bloque, mira la transacción coinbase en la cadena. En un pool no custodial tu dirección se escribe en el coinbase antes de que empiece el hasheo, así que un bloque real es visible a tu propio nombre y nadie puede moverlo.
• Si tienes curiosidad por saber cuán cerca has estado, nuestro artículo mejor share explicado cubre cómo leer esas cifras, y la calculadora de probabilidades convierte hashrate en expectativas realistas. La página del pool de eCash lista la dificultad actual y todos los endpoints regionales, el generador de configuración construye los ajustes stratum, y los datos en vivo de bloques y workers están en el panel del pool.

Si ejecutas tu propio nodo de eCash para minar en solitario, hay un elemento de configuración que importa. Un nodo necesita 17 bloques de tiempos de llegada de cabecera registrados antes de poder calcular el objetivo en tiempo real. Hasta que los tenga, puede construir plantillas con una dificultad demasiado baja y ver sus bloques aparcados. Poner persistrecentheaderstime=1 guarda esos tiempos de referencia en disco y los recarga al reiniciar, lo que cierra el hueco.

Fuentes

• Documentación de minería de eCash — los campos RTT de la plantilla de bloque, la implementación de referencia del cálculo del objetivo y los coeficientes de filtro publicados
• Heartbeat Upgrade: A Steady Pulse for eCash — la justificación, el problema del salto entre cadenas y el papel del post-consenso de Avalanche
• Código fuente de Bitcoin ABC — src/policy/block/rtt.cpp, que contiene la fórmula, las constantes de ventana y la política de aparcamiento
• Software de minería en solitario para eCash — cómo el objetivo en tiempo real se convierte en la dificultad de red reportada en eCash

Las cifras de verificación de este artículo se produjeron evaluando la fórmula publicada contra los logs de un nodo de eCash en vivo el 2 de agosto de 2026 y comparando los resultados valor por valor.