DigiByte: por qué tu share no fue un bloque

MultiShield de DigiByte recalcula el objetivo de minería SHA-256 cada vez que llega un bloque en cualquiera de sus cinco algoritmos — de media cada 15 segundos. La dificultad de red que ves en un explorador, un dashboard o un informe de minería es una instantánea ya obsoleta. Un share que supera ese valor solo es un bloque válido si supera el objetivo vigente en el segundo exacto en que llega al pool. Es la razón más común por la que un minero solo de DigiByte ve un share récord y no gana nada.

Puntos clave

• En DigiByte el objetivo SHA-256 se recalcula cada vez que llega un bloque en cualquiera de los cinco algoritmos, no solo cuando se encuentra un bloque SHA-256.
• En una ventana de 90 minutos, la dificultad de los bloques SHA-256 fue de 418 millones a 1,12 mil millones — un factor de 2,7.
• En un solo tramo de dos minutos el objetivo activo subió un 75%, de 748 millones a 1,31 mil millones.
• El valor de un share depende del objetivo en el segundo en que llega. El mismo share puede quedarse corto en un momento y ganar uno o dos minutos después.
• Nada de esto significa que se perdiera un bloque. Un share por debajo del objetivo activo nunca se envía como bloque, así que no hay nada que dejar huérfano, rechazar u ocultar.

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

Un minero solo de DigiByte nos envió un informe cuidadoso y bien documentado. Su minero había producido un share de unos 997 millones de dificultad. Un informe de minería generado aproximadamente una hora después mostraba una dificultad de red de 531 millones — lo que convertía el share en casi el doble del objetivo. Aun así, no apareció ningún bloque. Había comprobado la API del pool, confirmado que el share se había recibido y aceptado, y no había encontrado ningún registro de rechazo ni de share obsoleto. Según cada número que podía ver, debería haber sido un bloque.

Los números que podía ver eran reales. También eran los números equivocados.

Rastreamos el share en los logs del pool. Llegó entre las 06:26:31 y las 06:27:31 UTC del 4 de octubre de 2026. Durante ese minuto la red no exigía 531 millones. Exigía de 1,13 a 1,21 mil millones. El share alcanzó entre el 82,7% y el 88,1% de lo necesario.

La cifra de 531 millones era la dificultad una hora después, con el pico ya pasado. Y desde las 06:28:37 — uno o dos minutos después de que llegara el share — el objetivo cayó por debajo de 997 millones. El mismo share, uno o dos minutos más tarde, habría sido un bloque.

¿Por qué se mueve tanto la dificultad de DigiByte?

DigiByte reparte la producción de bloques entre cinco algoritmos de minería independientes — SHA-256, Scrypt, Skein, Qubit y Odocrypt — cada uno de los cuales mina aproximadamente uno de cada cinco bloques, cada uno con su propia dificultad. La cadena apunta a un bloque cada 15 segundos en total, así que el carril SHA-256 promedia un bloque cada 75 segundos.

La dificultad de cada carril la gestiona MultiShield, la extensión multialgoritmo de DigiShield que DigiByte introdujo en 2014. Mientras Bitcoin reajusta una vez cada 2.016 bloques, MultiShield recalcula la dificultad en cada bloque.

El detalle que pilla por sorpresa a los mineros es que recalcula todos los carriles en cada bloque, no solo el que lo encontró. El propio código de consenso de DigiByte lo dice explícitamente, en un comentario sobre los parámetros de dificultad: la dificultad de un algoritmo puede bajar cuando un algoritmo distinto resuelve un bloque. Así que el objetivo SHA-256 no se queda quieto entre un bloque SHA-256 y otro. Cada bloque encontrado en Scrypt, Skein, Qubit u Odocrypt también lo mueve, y el resultado es un objetivo que cambia aproximadamente cada 15 segundos. Nuestro explicador de DigiByte cubre el algoritmo completo, leído directamente del código de consenso.

¿Qué hizo realmente el objetivo durante ese minuto?

Cada vez que llega un bloque nuevo, el pool construye un nuevo trabajo de minería y registra el objetivo que ese trabajo debe cumplir. Estos son los valores exactos que registraron los logs del pool en torno al share:

El share llegó entre las 06:26:31 y las 06:27:31, mientras el objetivo estaba en 1.205.245.749 y después en 1.130.849.418. Con 996.739.624 alcanzó entre el 82,7% y el 88,1% del requisito. El objetivo cayó por primera vez por debajo del share a las 06:28:37.

Qué provocó esa ola queda claro al añadir los bloques SHA-256 que la cadena produjo realmente en la misma ventana:

Llegaron tres bloques SHA-256 en 99 segundos — uno cada 33 segundos, frente a un ritmo esperado de uno cada 75. El carril SHA-256 iba muy por delante de los otros cuatro, y MultiShield subió su dificultad en respuesta, hasta un máximo de 1,31 mil millones. Después no llegó ningún bloque SHA-256 durante cuatro minutos y veinticuatro segundos. A medida que llegaban bloques en los otros algoritmos, el objetivo fue bajando, escalón a escalón. El share llegó justo después de la cresta, mientras el objetivo aún descendía.

Los valores registrados son el requisito real de la red, no una estimación. Cada uno de los cuatro bloques SHA-256 de arriba se minó exactamente al objetivo que el pool había registrado instantes antes, coincidiendo hasta la unidad. Los cuatro son verificables públicamente en cualquier explorador de DigiByte.

¿Por qué la dificultad del informe no coincidía con el objetivo?

Porque el informe captó un momento una hora después, y en DigiByte una hora es mucho tiempo.

Cualquier valor de dificultad que mires — en un explorador, un dashboard del pool, un informe de minería o una calculadora de rentabilidad — es el valor en el instante en que se leyó. En Bitcoin ese valor dura dos semanas. En DigiByte el objetivo SHA-256 se recalcula cada vez que cualquiera de los cinco algoritmos encuentra un bloque, así que un valor tomado a las 07:34 no dice casi nada sobre lo que se exigía a las 06:27.

En los noventa minutos en torno a este share, la dificultad de los bloques SHA-256 en la cadena fue de unos 418 millones a 1,12 mil millones — un factor de 2,7. Un share de 997 millones era holgadamente un bloque en la parte baja de ese rango y se quedaba holgadamente corto en la parte alta.

Hay otra trampa. Los exploradores publican la dificultad de cada bloque tal como se minó — el valor que se aplicó al ganador. No existe ningún registro público del objetivo vigente en los segundos entre bloques. El objetivo más alto del log de arriba, 1,31 mil millones, no aparece en ningún explorador, porque no se minó ningún bloque SHA-256 mientras estuvo vigente. Y sin embargo es justo en un momento así cuando ocurren los casi aciertos.

¿Por qué el objetivo puede saltar más que el límite del 8% de MultiShield?

Nuestro explicador de DigiByte señala que MultiShield limita su retarget: la dificultad puede caer hasta un 16% en un paso pero subir como mucho un 8%. Sin embargo, después de cada uno de los tres bloques SHA-256 rápidos de esta ventana, el objetivo subió más de un 20% — un 22,9%, un 22,7% y un 21,7%.

Los dos hechos no se contradicen, porque MultiShield mueve un carril de dos maneras distintas. Los límites del 8% y del 16% acotan el retarget promediado del propio carril. A eso se suma un ajuste por algoritmo del 4% que mueve el carril según vaya por detrás o por delante de los otros cuatro.

En esta ventana el segundo mecanismo produjo un claro diente de sierra. Cada bloque en otro algoritmo bajó el objetivo SHA-256 aproximadamente un 4–5%. Cada bloque SHA-256, llegado cuando el carril ya iba por delante, lo empujó bruscamente hacia arriba otra vez. Vuelve a leer el log de objetivos con esto en mente y el patrón es inconfundible: tres grandes escalones hacia arriba, cada uno tras un bloque SHA-256, y después una larga escalera hacia abajo.

¿En qué se diferencia del Real-Time Targeting de eCash?

El síntoma es idéntico — un share supera la dificultad publicada y no gana nada — pero el mecanismo no.

En eCash el destino de un share depende de cuánto hace que llegó el último bloque; lo documentamos en detalle en eCash RTT: por qué tu share solo no fue un bloque. En DigiByte depende de dónde estaba el objetivo SHA-256 tras el bloque más reciente en cualquier algoritmo. Ambos producen casi aciertos que, desde el lado del minero, parecen exactamente un bloque perdido.

¿Ocurre esto en Bitcoin o en las otras cadenas SHA-256?

No de esta forma. En la mayoría de las cadenas SHA-256 el objetivo se mantiene fijo durante todo un intervalo de bloque y solo cambia cuando esa cadena encuentra su siguiente bloque.

En Bitcoin y Bitcoin Cash, la dificultad que consultas es la que tenías que superar. En DigiByte el objetivo que decidió tu share existió unos pocos segundos y nunca se publicó en ninguna parte.

¿Se perdió el bloque, quedó huérfano o fue ocultado?

No — porque nunca hubo un bloque.

El pool registra un evento de resolución de bloque cada vez que un share alcanza el objetivo de red de su trabajo. Para este share no hubo ninguno. El pool lo evaluó frente al objetivo activo, lo encontró corto y lo aceptó como un share ordinario. No se ensambló ningún bloque, no se hizo ninguna llamada submitblock y no se envió nada a la red. No había nada que dejar huérfano, rechazar o perder.

En un pool no custodio esto se puede comprobar desde fuera. La dirección de pago del minero se escribe en la transacción coinbase de la plantilla de bloque antes de que empiece el hashing, así que cualquier bloque real aparece on-chain a nombre del minero, de forma permanente. Un share que nunca llegó a ser un bloque no deja ese rastro — y un bloque real no podría ocultarse si hubiera existido.

¿Qué debería hacer realmente un minero solo de DigiByte?

Casi nada — pero lee bien tus números.

• Trata cualquier valor de dificultad como una instantánea. Un best share por encima de la dificultad en tu dashboard o en el informe no es prueba de un bloque perdido. Es prueba de que el objetivo era más alto cuando llegó tu share.
• El best share que muestra el minero se calcula en local. Los mineros registran la dificultad de un hash en el instante en que lo encuentran, antes de que el pool haya respondido, y a menudo guardan un valor histórico que nunca se reinicia. Te dice que tu hardware tuvo un buen momento, no si ese momento era ganador.
• Deja que el vardiff gestione la dificultad de los shares. DigiByte reajusta en cada bloque, así que una dificultad fija de shares que sirve para una hora puede ser incorrecta la siguiente. Nuestra guía de configuración de DigiByte explica la configuración.
• Mantén baja la latencia. En una cadena de 15 segundos, un servidor cercano acorta el intervalo entre la aparición de un nuevo trabajo y el momento en que tu minero trabaja en él.
• Comprueba la coinbase, no el contador. Para saber si encontraste un bloque, busca tu dirección en una transacción coinbase on-chain.

Nada de esto cambia tus probabilidades a largo plazo. Las oscilaciones se compensan con el tiempo, por eso una probabilidad basada en la dificultad media — como en nuestra calculadora de probabilidades solo — sigue siendo la base correcta para tus expectativas. Las oscilaciones solo deciden qué casi aciertos concretos se convierten en bloques.

Fuentes

• Parámetros de consenso de DigiByte Core — la nota de que la dificultad se actualiza para cada algoritmo en cada bloque, y las constantes de MultiShield nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 y nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, el ajuste de dificultad de MultiShield (GetNextWorkRequiredV4)
• DigiByte (DGB) explicado para mineros — nuestro perfil completo de MultiShield, leído directamente del código de consenso
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman sobre MultiShield y el retarget en cada bloque

Los valores de objetivo de este artículo proceden de los logs del pool del 4 de octubre de 2026, registrados cada vez que se construía un nuevo trabajo de minería. Los cuatro bloques SHA-256 minados en la ventana — 24.323.739, 24.323.740, 24.323.742 y 24.323.752 — coinciden exactamente con el objetivo que el pool había registrado instantes antes de cada uno, lo que confirma que los valores registrados son el requisito real de la red. Todas las dificultades de bloque citadas son verificables públicamente en cualquier explorador de DigiByte.