Bitaxeのシェアが拒否・未反映になる理由

まず接続経路を確認します。マイナーが接続され、認証され、ジョブを受け取るまではacceptedシェアは期待できません。

1. ホスト、ポート、TCP/TLSを一致させます。ホスト専用欄にはプロトコルの接頭辞を入れません。
2. 端末ログでDNS、タイムアウト、TLSのメッセージを確認します。すべての保護を無効にせず、関係するネットワーク規則だけを調べてください。
3. 認証後にマイナーがジョブを受信していることを確認します。別のエンドポイントを試す前に現在の設定を保存してください。

connectedは一段階にすぎません。マイナーは有効なジョブを処理し、割り当てられたシェア目標を満たす結果を出す必要があります。

1. 端末ログで認証と受信ジョブを確認し、ハッシュ計算が動いていることも確認します。
2. 割り当てられたシェア難易度を確認します。低いハッシュレートでは反映がまばらになる理由を、下の待ち時間ツールで把握してください。
3. 送信したシェアへの実際の応答を確認します。エラーには原因別の対応が必要です。待ち時間を延ばしても拒否されたアドレスは直りません。

マイナー側の結果とダッシュボード更新を分けて考えます。テレメトリーフィードの遅延や停止だけでは、マイナー停止の証拠になりません。

1. 完全なウォレットアドレスとワーカー名を、マイナーの設定と照合します。
2. 古い合計値だけでなく、最後のacceptedシェア時刻とダッシュボードの集計期間を確認します。
3. 端末がaccepted応答を受け続けている場合は時刻を記録し、テレメトリー欠落についてサポートへ連絡してください。

すでに受け付けられないジョブに基づく計算かもしれません。ジョブ更新と接続性を調べてください。1回のping測定だけでは原因を特定できません。

1. 再接続や新規ジョブのメッセージを含め、正確な応答と発生時刻を記録します。
2. 電圧、周波数、プールを同時に変えずに接続の安定性を比較します。
3. ファームウェアとプールのログが同じジョブを示しているか確認します。理由がない、または曖昧な場合はサポートに問い合わせてください。

これらはstaleな計算とは別の理由です。duplicate送信数の割合が、そのまま失われたハッシュ時間の割合になるわけではありません。

1. duplicateの場合は、同じジョブやnonceの再送と再接続の動作を調べます。
2. low difficultyの場合は、マイナーに割り当てられた目標と送信結果、ファームウェアの難易度処理を比較します。
3. 対応を確認せず、別プールのパスワード難易度構文をコピーしないでください。運営者向けに短く匿名化したログ例を残します。

プールのハッシュレートは送信された計算からの推定値です。特にシェアが少ない時は、端末推定値と短いプール集計期間の値が変動します。

1. 同じ期間を比較し、推定値が安定するだけのacceptedシェアを待ちます。
2. ハッシュレートと一緒に、割り当て難易度、中断、実際の拒否理由を記録します。
3. プール変更後にbest shareや生のシェア数が増えても、各ハッシュのブロック発見確率が上がった証拠にはなりません。