Bitaxe 셰어가 거부되거나 보이지 않는 이유

연결 경로부터 확인하세요. 채굴기가 연결·인증되고 작업을 받기 전에는 승인된 셰어가 나오지 않습니다.

1. 호스트, 포트, TCP/TLS를 맞추고 분리된 호스트 필드에는 프로토콜 접두사를 넣지 마세요.
2. 장치 로그에서 DNS, 시간 초과, TLS 메시지를 확인하세요. 모든 보호를 끄지 말고 관련 네트워크 규칙만 점검하세요.
3. 인증 후 작업을 받는지 확인하고 다른 endpoint를 시도하기 전 현재 설정을 저장하세요.

연결은 한 단계일 뿐입니다. 유효한 작업과 지정된 셰어 목표를 충족한 결과가 필요합니다.

1. 장치 로그에서 인증과 수신 작업을 확인하고 해싱이 동작하는지 보세요.
2. 지정된 셰어 난이도를 확인하세요. 아래 대기 시간 도구는 낮은 해시레이트에서 피드백이 드문 이유를 보여 줍니다.
3. 제출 셰어의 실제 응답을 확인하세요. 오류는 별도 진단이 필요하며 기다린다고 거부된 주소가 고쳐지지 않습니다.

채굴기 결과와 대시보드 갱신을 구분하세요. 텔레메트리 지연이나 장애만으로 채굴기 중단이 입증되지는 않습니다.

1. 전체 지갑 주소와 워커 이름을 채굴기 설정과 대조하세요.
2. 오래된 합계뿐 아니라 마지막 승인 셰어 시각과 대시보드 시간 범위를 확인하세요.
3. 장치가 계속 accepted 응답을 받으면 시각을 기록하고 누락 텔레메트리를 지원팀에 문의하세요.

더 이상 허용되지 않는 작업을 참조할 수 있습니다. 작업 갱신과 연결을 조사하세요. 한 번의 ping으로 원인을 알 수 없습니다.

1. 재연결이나 새 작업 메시지를 포함해 정확한 응답과 발생 시각을 기록하세요.
2. 전압, 주파수, 풀을 동시에 바꾸지 말고 연결 안정성을 비교하세요.
3. 펌웨어와 풀 로그가 같은 작업을 설명하는지 확인하고 이유가 없거나 모호하면 지원팀에 문의하세요.

이 원인은 stale 작업과 다릅니다. 중복 제출 수가 곧 같은 비율의 해싱 시간 손실은 아닙니다.

1. Duplicate는 반복 작업·nonce 제출과 재연결 동작을 살펴보세요.
2. Low difficulty는 지정 target, 제출 결과, 펌웨어의 난이도 처리를 비교하세요.
3. 지원 여부 확인 없이 다른 풀의 비밀번호 난이도 문법을 복사하지 말고 짧게 가린 로그를 남기세요.

풀 해시레이트는 제출 작업으로 추정합니다. 장치 추정치와 짧은 풀 구간은 특히 셰어가 드물 때 달라질 수 있습니다.

1. 같은 시간 범위를 비교하고 추정치가 안정될 만큼 승인 작업을 모으세요.
2. 해시레이트와 함께 지정 난이도, 중단, 실제 거부 원인을 기록하세요.
3. 풀 변경 뒤 best share나 셰어 수가 높아져도 각 해시의 블록 확률이 좋아졌다는 증거는 아닙니다.