Stale Rate

SetNewPrevHash を受けた Stratum V2 は新しい前ブロックハッシュへの切替を要求し、準備済みジョブのうち指定された job_id だけが有効になります。以前の目標未満のハッシュを見つけただけでは現在の作業に使える保証はありません。診断には送信時刻だけでなく、ジョブの文脈と変更が必要です。 [Stratum V2 — Mining Protocol]

例として、同じ難易度の 100 提出のうち 98 が受理され、1 が stale、1 が別の理由で拒否されたとします。拒否された stale の割合は 1%、全拒否率は 2% です。異なる分子の説明であり、許容される運用しきい値ではありません。F2Pool は全提出 shares を rejection rate の基準にします。 [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]