Keddeh ViaBTC Configuration Guide

Start here

Configure ViaBTC mining transport and read-only account observations as separate connections. A miner receives jobs and submits shares over Stratum; the HTTPS API reports pool data. This public-safe configuration guide contains no internal-host diagnostics, credentials or deployment instructions. It is a public draft, not a claim that any particular service is connected or producing accepted work.

Document control

Document ID: KEDDEH-MINING-PUBLIC-CONFIG-001. Version: 1.0. Date: 2026-10-11 UTC. Classification: Public draft prepared for review. Status: Public draft; technical review status remains Draft. Author: Aboudy Keddeh, Systems Architect. Publisher: Keddeh Systems. Rights holder: Aboudy Keddeh. Licence: KEDDEH-RESERVED-1.0.

Architecture and research direction: Aboudy Keddeh. AI-assisted source research and drafting: OpenAI ChatGPT. Technical approval and independent assessment are not recorded.

All rights reserved. No licence is granted by this document. Separate written permission governs reuse, redistribution and implementation, subject to applicable law. Third-party material retains its own rights.

Configure a BTC pool worker

1. Confirm the intended account or subaccount in ViaBTC and the actual mining device or software implementation. Record its source or firmware version and exact deployment target. Confirm coin BTC and compatible SHA256d work execution before applying a pool profile.

2. For standard BTC use stratum+tcp://btc.viabtc.io:3333 and alternate stratum+tcp://btc.viabtc.io:443. Smart Mining uses bitcoin.viabtc.io at the same documented ports. Do not silently switch between these modes. Port 443 in a stratum+tcp URL does not establish TLS. [V8, V11]

3. The login structure is userID.workerID. ViaBTC states: “WorkerID should consist of numbers and lowercase letters within 64 characters.” This is the worker suffix rule, not a claim about every Keddeh identity or account-name character. A pool password is optional for the documented setup; never put an API key, account password, or wallet address in that field. [V8]

4. Enter the documented primary and alternate rows in the actual miner. Preserve a copy of the prior configuration. Apply only the intended profile, then verify the device reports the expected active endpoint and full worker login. Failover behavior depends on the executing client. [V8]

5. Retain session logs showing subscription, authorization, jobs, submissions and their matched responses. Check ViaBTC worker activity after roughly 10–15 minutes of stable operation, while addressing explicit connection errors immediately. [V8, V11]

Connect read only pool observations

Use the documented HTTPS API base https://www.viabtc.net. A successful response has JSON code 0; HTTP success alone is insufficient. Daily data defaults to UTC+8, and utc=true is available only on endpoints documenting that parameter. [V2]

An existing approved API binding and permitted egress IP are required for API reads. Authentication uses X-API-KEY; “Signature Required: No” does not mean unauthenticated. The official guide requires an IP allowlist and describes subaccount inheritance. Do not create credentials or broaden an allowlist as an automatic troubleshooting step. These API requirements are not prerequisites for Stratum mining. [V3]

GET /res/openapi/v1/hashrate?coin=BTC returns account 10-minute, 1-hour and 24-hour hashrate in hash/s, plus worker counts. These are rolling pool estimates, not the local hardware instantaneous rate. [V4]

GET /res/openapi/v1/hashrate/worker?coin=BTC supports group_id, worker_status, page and limit. Follow has_next and total_page; default limit is 50. Retain the account scope, coin, worker_id, worker_name, source timestamp and capture time. Do not mark absent later pages as offline. [V5]

GET /res/openapi/v1/hashrate/worker/{worker_id} returns one worker’s rolling rates, status, last_active and reject_rate. The wiki index has a misspelled worker-info link that redirects to Home; use the actual acquire_miner_hashrate_info reference in this guide. [V6]

These three GET endpoints specify no signature requirement. Some other API operations use millisecond tonce and HMAC-SHA256; implement signing only for a documented endpoint that requires it. No signed financial or withdrawal operation is part of this support profile. [V3]

Operational recommendation: start with a conservative configurable polling interval, coalesce reads and use bounded backoff for transient failures. The reviewed wiki pages do not state a verified request quota. Preserve last-good data with its age and an explicit error state rather than rendering failed reads as zero hashrate.

Interpret metrics without fabricating evidence

Accepted and rejected counts should come from matched share-submission responses in the executing client or directly from a documented pool source. Count resolved submissions once. Keep pending submissions separate. A rejected share is not automatically a connection failure. [V10]

Stale is a reason for rejection when a job is no longer accepted. Duplicate and low-difficulty reasons identify different faults. If the source includes stale inside rejected totals, do not add it again when calculating total submissions. Preserve the original classification and time interval. [V10, V11]

The reviewed ViaBTC worker JSON includes reject_rate but no accepted, rejected or stale counts. Its example does not define reject_rate scaling or aggregation interval. Retain it as a raw provider field until verified; do not manufacture counters from it or assume whether 1 means one percent or a fraction. [V5, V6]

For a local count-derived rejection rate, use rejected divided by accepted plus rejected within the same interval and clearly label the local basis. With no resolved submissions the rate is unavailable, not 0% rejection or 100% efficiency. For variable difficulty, any share-derived hashrate needs accumulated work per accepted share, not current difficulty multiplied by every historical share.

ViaBTC describes active workers as connected and contributing, offline as without work for 20 minutes to one day, and inactive beyond one day. Preserve the API raw status values separately; do not assume its active/unactive filter expresses the full user-interface taxonomy. [V9, V5]

Diagnose the failing layer

DNS or TCP failure: verify the intended hostname, coin, endpoint and outbound route. Compare with a known-working device on the same network. A web-page fetch or ping does not prove Stratum operation. Check connection-refused versus timeout versus remote close before changing settings. [V10]

Authorization failure: compare the actual full login with the intended account/subaccount and worker alias. Do not troubleshoot it by adding an HTTP API key to Stratum. Preserve the pool error text. [V10]

Connected with zero credited work: inspect incoming jobs, local hash activity, candidate generation, submitted requests and matching pool responses. Separate no submissions from rejected submissions. Pool-estimated and local rates can differ because they measure different windows. [V11]

Rising stale rate: examine reconnects and delayed work delivery. For duplicate or low-difficulty submissions inspect job identity, difficulty updates, nonce handling and client/proxy compatibility. Change one variable at a time and compare equal-duration windows. Avoid an unsupported universal rejection threshold. [V10, V11]

API code 2: inspect arguments; 5001: coin type; 5003: worker ID/account scope; 5008: group ID; 12001: credential binding; 12002: signature serialization when applicable; 12003: system time and tonce; 12004: actual egress IP versus approved allowlist. Redact request headers and secrets from escalation records. [V7]

Support evidence and acceptance record

Record: incident ID; UTC start/end; native service identity; source/firmware version; actual execution target; coin and mode; endpoint/port and transport; approved alias mapping; reconnects; job arrival; submitted/resolved/pending shares; exact sanitized rejection reasons; pool worker ID; rolling rates and windows; last-active and capture times.

Include separate checks for configuration applied, expected process running, Stratum authorized, fresh jobs received, valid-share implementation identified, pool acceptance observed, worker readback reconciled and any authorized failover recovered. Mark unavailable evidence as pending. A source review, config download or UI animation cannot pass execution checks.

Before sending a support ticket, remove API headers, credentials, wallet information, raw packet captures and unnecessary internal addresses. Retain a private complete record and send only the relevant redacted extract to the approved support recipient. No support ticket has been sent by this package.

Verify the execution mechanism

HTML engines can execute software through their browser host. Native wrappers can provide scheduling, state identity, locality and recovery; each benefit needs a separate test. Wrapping alone does not create compute capacity or prove faster hashing.

The pool-valid path is exact job, complete coinbase and merkle reconstruction, correctly ordered 80-byte header, SHA256d digest meeting the assigned target, submission of the same tested candidate, and a matching current-session pool response. Stale-job handling and nonce binding are part of that path.

Measure actual hash attempts, time and resources over the same workload when comparing implementations. Energy claims additionally require power measurements. A single known vector checks arithmetic but supplies no meaningful hashrate or efficiency benchmark. Browser JavaScript, a VFS adapter and a native binary ABI are separate execution contracts; qualify whichever path is actually used.

References

V1 — ViaBTC API overview. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki

V2 — API description. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/api_description

V3 — API authentication. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/api_authentication

V4 — Account hashrate. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/acquire_account_hashrate

V5 — Worker list. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/acquire_miner_hahrate

V6 — Worker details. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/acquire_miner_hashrate_info

V7 — API error codes. Accessed 2026-10-11. https://github.com/viabtc/viapool_api/wiki/error_code

V8 — BTC mining setup. Accessed 2026-10-11. https://support.viabtc.com/hc/en-us/articles/7207401012879-BTC-Mining

V9 — Worker management. Accessed 2026-10-11. https://support.viabtc.com/hc/en-us/articles/7207414575759-How-to-Manage-Workers

V10 — Stratum connection diagnostics. Accessed 2026-10-11. https://www.viabtc.com/en/blog/Mining-how-to-troubleshoot-stratum-connection-drops-on-asic-miners-734?category=0

V11 — Mining connection and share troubleshooting. Accessed 2026-10-11. https://www.viabtc.com/en/blog/Mining-mining-pool-connection-troubleshooting-fix-stratum-errors-offline-workers-and-rejected-shares-946?category=0

Revision history

1.0 — 2026-10-11: separated public-safe ViaBTC setup and support guidance from private operational evidence. Published as a public draft; technical review status remains Draft.