Las shares aportan información, no progreso hacia un bloque
La dificultad de share del pool fija un umbral para informar del trabajo. Aumentarla puede reducir el número de shares comunicadas sin cambiar el objetivo de la red Bitcoin. Por eso, los recuentos de dos pools no son directamente comparables. Use el trabajo aceptado, las ventanas de tiempo y los motivos de error para evaluar el funcionamiento, y trate el récord de mayor dificultad como un resultado pasado.
- No optimice la configuración buscando simplemente el contador de shares más alto.
- No trate la Mejor dificultad como un medidor de porcentaje completo.
- Mantenga la dificultad de share separada de la dificultad de la red en cualquier estimación.
Leer un rechazo antes de cambiar la configuración
Un job stale o caducado, un envío duplicado y un resultado por debajo del objetivo requieren análisis distintos. Registre el motivo exacto junto con los mensajes de job, reconexión y conexión cercanos. Si el panel solo ofrece totales, no puede indicar qué categoría aumentó. Los pools pueden etiquetar los errores de forma diferente; confirme el significado con el operador cuando sea ambiguo.
- Registre el firmware, el punto final, la hora UTC y la respuesta exacta.
- Cambie una variable relevante por comparación.
- Una tasa de rechazo basada en el conteo no es automáticamente la misma fracción de la probabilidad perdida de bloque.
Consulta la guía original.: ESP-Miner / AxeOS · GitHub · Bitcoin Developer Guide · CKPool FAQ
Comparar telemetría con ventanas coincidentes
La estimación instantánea del minero y la estimación del pool basada en el trabajo comunicado no tienen por qué coincidir durante un período corto. Las shares escasas de alta dificultad aumentan esa variación. Busque respuestas aceptadas recientes, el worker correcto y el mismo intervalo antes de deducir que existe un fallo. Los datos ausentes deben seguir marcados como no disponibles, no interpretarse silenciosamente como trabajo cero.
- Compare las observaciones a nivel de worker antes de combinar varias máquinas.
- Observe las interrupciones y los cambios de configuración dentro de la ventana de comparación.
- Si las respuestas aceptadas continúan mientras se detienen las estadísticas, investigue la telemetría por separado.
Preparar una solicitud de soporte que pueda ser investigada.
Mantenga un breve extracto del registro sobre la falla en lugar de compartir un volcado completo del dispositivo. Incluya modelo, firmware instalado, transporte, host del pool, dificultad asignada, ventana de tiempo y pasos ya probados. Elimine los detalles de la red privada y los identificadores personales que sean innecesarios. Contacta apóyate con esa evidencia; esta página no carga sus registros.
- Nunca incluya frases semilla, claves privadas o contraseñas de administración de dispositivos.
- Mantenga tanto el error como el contexto laboral circundante.
- Guarde la configuración del pool de trabajo antes de una prueba controlada en otro punto final.
¿Cuándo es útil cambiar de pool?
Un conmutador controlado puede ayudar a distinguir el comportamiento específico de la conexión si las condiciones del hardware y de la red siguen siendo comparables. No puede resolver todos los problemas de firmware ni clasificar los pools a partir de una breve muestra. Si el error persiste, conserve ambas observaciones y vuelva al motivo de envío real en lugar de buscar una share de mayor dificultad.
Contenido actualizado: 3 de octubre de 2026 · Política y fuentes verificadas: 6 de septiembre de 2026
Preguntas sobre shares aceptadas y rechazadas
¿Qué porcentaje de rechazo es aceptable?
No existe un porcentaje único que diagnostique todos los dispositivos y pools. La ventana de observación, la dificultad de compartir, el tamaño de la muestra y los motivos del rechazo son importantes. Investigue un cambio persistente con registros y condiciones coincidentes. Evite asumir que cada envío rechazado representa una cantidad igual de tiempo de hash o un candidato bloque igualmente valioso.
¿Reducir la dificultad de las shares mejorará mis probabilidades de encontrar un bloque?
Cambiar la dificultad de share modifica el umbral de notificación; no reduce el objetivo de la red Bitcoin. Enviar shares con más frecuencia puede ofrecer respuestas más rápidas, pero los envíos innecesarios también generan tráfico. Siga el comportamiento de dificultad documentado por el pool y el firmware, sin optimizar el contador como si midiera boletos de lotería.
¿Cuánto tiempo debo esperar para recibir la primera share aceptada?
Depende del hashrate y de la dificultad de share asignada, con una variación aleatoria alrededor del promedio. La herramienta del tiempo de espera ilustra esa relación. Primero confirme la conexión, autorización y trabajos recibidos. Una espera estadística no puede corregir credenciales no válidas, una discrepancia en el transporte o un minero que no realiza hash, así que inspeccione esas etapas por separado.
¿Puede el panel de la wallet identificar shares obsoletas o duplicadas?
El panel actual de SoloMining expone recuentos y una tasa de rechazo, no un desglose completo de los motivos de rechazo. Utilice el registro de respuestas del dispositivo para encontrar un motivo cuando esté disponible. Si la respuesta falta o es ambigua, preserve su contexto y solicite apoyo; el porcentaje por sí solo no puede proporcionar de forma fiable la clasificación que falta.
¿Por qué mejoró mi mejor dificultad después de un cambio de pool?
Un resultado de alta dificultad puede ocurrir por casualidad. Un registro posterior no establece que el nuevo pool mejoró la probabilidad de cada hash efectivo. Compare el comportamiento aceptado de trabajo y conexión por separado. Ni las shares acumuladas ni el mejor resultado anterior acercan el siguiente hash independiente a un bloque válido.