Stale Rate

收到 SetNewPrevHash 后，Stratum V2 要求切换到新的前一区块哈希；已准备的任务中仅被引用的 job_id 仍有效。因此，找到低于原目标的哈希，并不保证它适用于当前工作。诊断需要任务上下文及其变化，而不只是发送时间。 [Stratum V2 — Mining Protocol]

示例：100 次相同难度的提交中，98 次接受，1 次作为 stale 拒绝，1 次因其他原因拒绝。被拒绝的 stale 比例为 1%，总拒绝率则为 2%。这是不同分子的说明，不是可接受的运行阈值。F2Pool 将 rejection rate 定义为被拒绝 shares 占全部提交的比例。 [F2Pool — Rejection and Staled rates]

Braiins 将难度为 d 的 share 换算成 d 个基础工作单位。若示例中有一份难度 1 的 stale share 和一份难度 9 的已接受 share，按数量算是 50%，按权重算却是 10%。比较的分子和分母必须使用相同单位及难度约定。 [Braiins — Share difficulty accounting]

F2Pool 文档区分有报酬的 “Staled” shares 与没有报酬的被拒绝 stale shares。这种政策不能推广到每个矿池。将百分比换算为损失收入前，应核对实际类别、接受规则和结算；指标名称并不充分。 [F2Pool — Rejection and Staled rates]

Stratum V2 允许批量 SubmitShares.Success。new_submits_accepted_count 表示新确认的提交数量，new_shares_sum 表示其难度之和。因此，服务器回复数量不等于已接受 shares 的数量。SubmitShares.Error 包含 sequence_number 和 error_code；不区分原因就不能把每个错误都叫作 stale。 [Stratum V2 — Mining Protocol]

BIP152 讨论 P2P 节点间的 Compact Block Relay，而非矿池 shares 记账。减少传输数据可能影响区块到达延迟，但本身无法给出矿工的 Stale Rate。网络竞争区块的比例不能替代某个 worker 迟到提交的比例。 [BIP152 — Compact Block Relay]

Braiins 监控区分 shares_5m、shares_60m 和 shares_24h。计算自己的比率时，分子分母应采用相同时间窗口和 worker 范围。没有观察到提交并不意味着测得 0% 损失；该比率未定义。缺失回复或监控空档也不自动属于 stale。 [Braiins — Worker monitoring windows]

F2Pool 将 stale 与网络条件联系起来，但其他拒绝原因还包括固件错误和超频。Braiins 区分服务器可达性测试与实际性能。应检查同一时期的任务日志、拒绝原因和连接；仅靠 ping 或更低的汇总百分比，无法证明原因已经消除。 [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]