Stale Rate es la proporción de sucesos o trabajo ponderado clasificados como stale en un conjunto definido con precisión. Aquí se trata principalmente de shares de pools que llegan o se procesan en un contexto de tarea ya desactualizado.
Al recibir SetNewPrevHash, Stratum V2 exige cambiar al nuevo hash anterior; entre las tareas preparadas solo sigue válida la job_id referenciada. Encontrar un hash inferior al objetivo anterior no garantiza su utilidad para el trabajo actual. El diagnóstico requiere contexto y cambios de tarea, no solo la hora de envío. [Stratum V2 — Mining Protocol]
Ejemplo: de 100 envíos de igual dificultad, 98 se aceptan, 1 se rechaza como stale y 1 por otra razón. Los stale rechazados representan 1%, pero el rechazo total es 2%. Son numeradores distintos, no límites operativos aceptables. F2Pool define rejection rate respecto a todas las shares enviadas. [F2Pool — Rejection and Staled rates]
Braiins convierte una share de dificultad d en d unidades básicas de trabajo. Si el ejemplo tiene una stale de dificultad 1 y una aceptada de dificultad 9, la proporción por cantidad es 50%, pero por peso es 10%. Numeradores y denominadores comparados deben usar la misma unidad y convención de dificultad. [Braiins — Share difficulty accounting]
F2Pool distingue en su documentación las shares “Staled” remuneradas de las stale rechazadas sin recompensa. Esa política no se puede generalizar a todos los pools. Antes de convertir el porcentaje en ingresos perdidos, revisa la categoría real, las reglas de aceptación y la liquidación; el nombre del indicador no basta. [F2Pool — Rejection and Staled rates]
Stratum V2 permite SubmitShares.Success por lotes. new_submits_accepted_count indica cuántos envíos nuevos se reconocen y new_shares_sum suma sus dificultades. Contar respuestas del servidor no equivale a contar shares aceptadas. SubmitShares.Error lleva sequence_number y error_code; sin distinguir motivos no se puede llamar stale a cada error. [Stratum V2 — Mining Protocol]
BIP152 trata Compact Block Relay entre nodos P2P, no la contabilidad de shares del pool. Reducir los datos transferidos puede afectar la latencia de bloques, pero no da por sí solo el Stale Rate del minero. La proporción de bloques competidores en la red no sustituye la de envíos tardíos de un worker. [BIP152 — Compact Block Relay]
El monitoreo de Braiins distingue shares_5m, shares_60m y shares_24h. Usa la misma ventana temporal y conjunto de workers en numerador y denominador. Cero envíos observados no significa una pérdida medida de 0%: el cociente no está definido. Las respuestas ausentes y los huecos de monitoreo no son automáticamente stale. [Braiins — Worker monitoring windows]
F2Pool relaciona stale con la red, pero menciona errores de firmware y overclocking para otros rechazos. Braiins distingue la prueba de accesibilidad del servidor del rendimiento real. Examina registros de tareas, motivos de rechazo y conexiones del mismo periodo; un ping o un porcentaje agregado menor no demuestra que la causa desapareció. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]
Para obtener la imagen más completa, lee esta entrada junto con Mining Share, Share Difficulty, Mining Latency, Pool Fee. También enlazan con esta entrada Mining Latency, Disponibilidad minera.