Muchos mineros ven un contador rojo en una página de estado, una caída en el hashrate reportado por el pool, o un porcentaje de rechazo en aumento, y concluyen que un ASIC ha fallado. Estas señales provienen de capas diferentes del proceso de minería, y tratarlas como intercambiables conduce a un diagnóstico equivocado. Un error de hardware es evidencia reportada por el propio minero. Una share rechazada es una decisión tomada por el pool. Ambas cosas solo están relacionadas en algunos casos.\n\nEste artículo separa la telemetría del lado del minero de la validación de shares del lado del pool, explica qué puede y qué no puede demostrar cada categoría, y describe una secuencia de resolución de problemas que comienza por la capa correcta: hardware, firmware o ajuste (tuning), red local, o conexión con el pool.\n\n## Dos capas diferentes del mismo proceso de minería\nUn trabajo de minería atraviesa varias etapas distintas antes de contabilizarse como trabajo aceptado. El ASIC recibe un trabajo del pool y comienza a hashear localmente. Su firmware monitoriza las condiciones locales: número de chips, temperatura de la placa, velocidad del ventilador, hashrate local y contadores internos de errores de hardware. El minero envía entonces soluciones candidatas, llamadas shares, al pool mediante una conexión Stratum. El pool valida cada share enviada frente al trabajo que emitió y el objetivo de dificultad que asignó, y devuelve una respuesta de aceptada o rechazada, con un motivo en el caso de rechazo.\n\nLas dos primeras etapas solo son observadas por el minero. Las dos últimas etapas solo son observadas por el pool. Un fallo que se origina en una etapa no produce automáticamente un síntoma equivalente en la otra.\n\n## Qué indica realmente un error de hardware del ASIC\nLos contadores de errores de hardware (HW) son telemetría del lado del minero, mostrada habitualmente en la propia página de estado del ASIC o en la interfaz del firmware. Según la documentación de Bitmain sobre la página de estado de sus mineros, puede producirse un número limitado de errores de HW mientras los chips operan a plena capacidad, y el minero puede corregir estos errores internamente y continuar hasheando sin interrupción (Bitmain Support). Por lo tanto, un recuento de HW distinto de cero no constituye, por sí solo, evidencia concluyente de que un minero haya fallado o de que el pool esté rechazando un volumen equivalente de shares.\n\nUn aumento en el recuento de HW merece una atención más detallada cuando aparece junto con otras señales, como por ejemplo:\n- menor hashrate local en la misma placa o unidad;\n- un número de chips detectados reducido o un indicador de fallo en el estado del ASIC;\n- una hashboard ausente o con salida nula;\n- un evento de protección térmica o un mensaje de fallo de ventilador/fuente de alimentación (PSU) en los registros;\n- reinicios inesperados repetidos;\n- un aumento en los rechazos de shares inválidas tras un cambio reciente de frecuencia o voltaje.\n\nNinguna de estas condiciones establece un recuento "normal" fijo de errores de HW aplicable a todos los modelos o versiones de firmware, y este artículo no presenta uno. La comparación más útil es con la línea base reciente propia de la unidad, no con una cifra asumida de la industria.\n\n## Qué indica realmente una share rechazada\nLas shares rechazadas son la categoría general para cualquier envío que el pool no acepta. El motivo específico importa más que el recuento total, porque cada motivo apunta a una parte diferente del sistema.\n\n\n\n

\n\n\n\nUna share obsoleta (stale) es una share que habría sido válida para un trabajo que el pool ya ha reemplazado, comúnmente porque la punta activa de la blockchain cambió, o porque la conexión del minero retrasó la entrega del nuevo trabajo o el retorno de la solución. Una share obsoleta no es evidencia de un fallo de hardware; refleja los tiempos en la conexión entre el minero y el pool.\n\nUna share inválida es un envío que no supera la comprobación de validación del pool para el trabajo y el objetivo que se le asignó. Esta categoría es la que más plausiblemente se relaciona con un ASIC inestable o mal configurado.\n\nLos rechazos por duplicado y por baja dificultad apuntan hacia el software del minero, un proxy o un comportamiento de configuración, más que hacia daños a nivel de chip. Un rechazo por duplicado, en particular, no representa necesariamente trabajo recién perdido, ya que el envío original podría haber sido aceptado previamente.

Cuándo la inestabilidad del hardware puede provocar shares rechazadas

Un ASIC inestable puede producir cálculos inválidos o envíos con formato incorrecto, y esta es la única área en la que el estado del hardware y el rechazo por parte del pool están relacionados de forma significativa. Ajustes agresivos de frecuencia o voltaje, temperatura elevada del chip, suministro eléctrico marginal, placas dañadas e incompatibilidad de firmware pueden manifestarse primero en la telemetría del hardware y, posteriormente, coincidir con un aumento en los rechazos por shares inválidas.

Esta relación solo funciona en una dirección a efectos de diagnóstico: la presencia de errores de hardware justifica revisar las shares inválidas, pero no demuestra que un aumento simultáneo de shares obsoletas (stale) tenga origen en el hardware. Las shares obsoletas y las shares inválidas deben investigarse por separado, incluso cuando se producen en el mismo período.

Cuándo las shares rechazadas no son un problema de hardware

Las shares obsoletas (stale) son el ejemplo más claro de una categoría de rechazo que normalmente no está relacionada con el estado del chip. Cuando la red de Bitcoin produce un nuevo bloque, el trabajo de minería anterior queda desactualizado, y los pools distribuyen trabajo nuevo basado en la punta de cadena más reciente para que los mineros sigan trabajando hacia un objetivo válido (Bitcoin Developer Guide, Mining). Si la conexión de un minero entrega ese trabajo actualizado con retraso, o si su solución enviada llega después de que el pool ya haya avanzado, el pool rechaza como obsoleta (stale) una prueba de trabajo que, de otro modo, sería válida.

Esta condición puede afectar simultáneamente a varios mineros, por lo demás sanos, en una misma instalación, lo cual es una pista diagnóstica útil: un fallo de hardware normalmente se limita a una sola unidad, mientras que una ruta de red compartida, un endpoint del pool o un problema de enrutamiento pueden elevar el recuento de shares obsoletas en muchos workers al mismo tiempo. La guía de ViaBTC para reducir las shares obsoletas identifica la selección del endpoint del pool y el enrutamiento de red, y no el estado del chip, como las principales áreas que revisar para este tipo de rechazo (ViaBTC).

Comparación entre el hashrate local y el hashrate reportado por el pool

El hashrate local del ASIC y el hashrate reportado por el pool se miden de forma diferente y no deben compararse como si fueran la misma cifra. El ASIC reporta su propia actividad utilizando una lógica definida por el firmware y un período de promediado que no es uniforme entre modelos. Un pool, en cambio, estima el hashrate a partir de las shares que ha recibido dentro de su propia ventana de reporte.

La documentación de ViaBTC indica que su cifra de hashrate en tiempo real se basa en los 10 minutos anteriores, mientras que su cifra de hashrate diario se basa en las 24 horas anteriores (ViaBTC). Un minero que se reinició, se reconectó o experimentó un breve pico de rechazos dentro de esa ventana mostrará una cifra estimada por el pool más baja, incluso si su hashrate local actual ya ha vuelto a la normalidad. Antes de concluir que una discrepancia refleja un problema de hardware, confirme que ambas cifras cubren ventanas de tiempo comparables y que el período no incluye un reinicio, un tiempo de inactividad o un cambio reciente de endpoint.

Un cálculo de porcentaje de rechazo, utilizado con precaución

Cuando un pool muestra los recuentos de shares aceptadas y rechazadas para el mismo período definido, se puede calcular un porcentaje de rechazo en bruto de la siguiente manera:

Porcentaje de rechazo en bruto = Recuento de shares rechazadas ÷ (Recuento de shares aceptadas + Recuento de shares rechazadas) × 100

Esta es una cifra de diagnóstico basada en recuentos, no una métrica estándar de rentabilidad. Solo tiene sentido cuando los totales de aceptadas y rechazadas corresponden al mismo período y a categorías comparables, y asume una dificultad de share igual entre las shares contabilizadas; si la dificultad de las shares varía, un recuento en bruto no representará la misma proporción de trabajo subyacente que una cifra ponderada por dificultad. Un porcentaje de rechazo no debe convertirse directamente en una supuesta pérdida porcentual de ingresos en BTC, ya que el método de pago, el tipo de rechazo y el tratamiento contable afectan al resultado de formas distintas.

Una secuencia práctica de resolución de problemas

1. Lea el motivo de rechazo específico del pool antes de reaccionar a un porcentaje total de rechazo.
2. Determine el alcance: ¿se ve afectado un worker, un rack o todo el sitio?
3. Revise la propia página de estado y los registros del minero en busca de recuento de chips, estado de las placas, temperatura, velocidad de los ventiladores, mensajes de la PSU y reinicios recientes.
4. Compruebe qué ha cambiado recientemente: actualización de firmware, ajuste de frecuencia o voltaje, trabajos de refrigeración, cambio de red o un nuevo endpoint de pool.
5. Para los shares obsoletos (stale shares), empiece por la conectividad: confirme los endpoints documentados actuales del pool y compare períodos operativos equivalentes antes de asumir una causa de hardware.
6. Para los shares inválidos, revise la refrigeración, el suministro eléctrico, la versión de firmware y los cambios recientes de ajuste (tuning); cuando sea apropiado, volver a una configuración previamente estable puede ayudar a aislar la variable.
7. Para chips faltantes, placas faltantes, apagado térmico persistente o fallos de PSU, siga el proceso de diagnóstico y reparación documentado por el fabricante en lugar de tratar la condición como un problema de conectividad.

Conclusión

Un error de hardware es evidencia reportada por el minero. Un share rechazado es una decisión tomada por el pool. Ambos pueden compartir una causa raíz, pero con frecuencia no es así, y diagnosticarlos con la misma lista de verificación conduce a esfuerzos desperdiciados: reflashear el firmware para un problema de enrutamiento, o perseguir una solución de red para una placa de hash defectuosa. El motivo de rechazo, los propios registros del minero y una ventana de medición equiparada proporcionan, en conjunto, una base de diagnóstico más fiable que cualquier contador aislado considerado por sí solo.

Preguntas frecuentes

¿Un recuento alto de errores de HW significa que mi ASIC está fallando?

No necesariamente. Algunos errores de HW pueden ocurrir durante el funcionamiento normal a plena capacidad y pueden ser corregidos por el propio minero sin afectar al hashing continuo. Un recuento creciente combinado con una reducción del hashrate, una placa faltante o alarmas térmicas justifica una inspección más detallada; el recuento por sí solo no confirma un fallo.

¿Los shares obsoletos (stale shares) son señal de daño en el hardware?

Generalmente no. Un share obsoleto es una prueba de trabajo válida enviada para un job que el pool ya ha reemplazado, comúnmente debido a la latencia de red, pérdida de paquetes o entrega retrasada del job, en lugar de un fallo a nivel de chip.

¿Por qué mi hashrate reportado por el pool difiere de mi hashrate local?

Las dos cifras utilizan métodos de medición y ventanas temporales diferentes. El hashrate local refleja la lectura propia del firmware del ASIC; el hashrate reportado por el pool es una estimación basada en shares durante el período de reporte indicado por el pool. Una discrepancia temporal tras un reinicio o una reconexión no indica por sí misma un problema de hardware.

¿Puede un porcentaje de rechazo indicarme cuántos ingresos en BTC he perdido?

No directamente. Un porcentaje de rechazo bruto es una cifra de diagnóstico basada en recuentos que asume una dificultad de share igual y un período de reporte equiparado; no se traduce en una cifra de ingresos exacta sin tener en cuenta el tipo de rechazo, el método de pago y la variación de la dificultad de los shares.

¿Qué debo revisar primero cuando los shares inválidos aumentan tras un cambio de ajuste (tuning)?

Revise la temperatura de los chips, los ajustes de reloj y voltaje, el suministro eléctrico y la compatibilidad del firmware, y considere volver a la última configuración estable conocida antes de probar más cambios.

Referencias

• Bitmain Support, "Miner Status Page Explained" — https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
• ViaBTC, "How to Reduce Stale Shares With Better Pool URL and Network Routing" — https://www.viabtc.com/en/blog/Mining-how-to-reduce-stale-shares-with-better-pool-url-and-network-routing-735
• ViaBTC, "Mining Pool With Real-Time Hashrate Monitoring: Understanding Measurement Windows and Latency Effects" — https://www.viabtc.com/en/blog/Mining-mining-pool-with-real-time-hashrate-monitoring-understanding-measurement-windows-and-latency-effects-941