Confirming that a Public Pool address is online requires more than just checking if the webpage loads; you must verify it at the node level. A frontend display showing "Worker Active" is merely a unilateral declaration from the pool server that it has received share submissions from that address—this is just statistical data pulled by the webpage from the server, and you cannot verify the authenticity of this claim from the browser itself. The real Stratum V1 handshake occurs between your TCH Miner and stratum+tcp://public-pool.io:3333 (or the corresponding mode port); the frontend does not participate in the handshake process.
1、Lightweight Verification: Log in to Public Pool via BTC Address
The essence of lightweight verification is a quick application-layer status check. When you enter your BTC address into the Public Pool.io frontend, it pulls statistics associated with that address from the pool server. However, the real Stratum V1 handshake occurs between your miner and the Stratum service at public-pool.io—the miner actively initiates a connection, subscribes to jobs, and submits shares.
A common mistake is to only check if the browser can load the page, ignoring the underlying TCP port connectivity, resulting in miners running idle for hours without notice.
According to the official Public Pool access information, the connection parameters for each mode are as follows:
| Mining Mode | Connection Address | Port | Protocol Type |
|---|---|---|---|
| Solo Mode | stratum+tcp://public-pool.io | 3333 | TCP |
| Solo + TLS Encryption | stratum+tls://public-pool.io | 4333 | TLS Encrypted |
| PPLNS Mode | stratum+tcp://public-pool.io | 13333 | TCP |
| PPLNS + TLS | stratum+tls://public-pool.io | 14333 | TLS Encrypted |
📌 Quick Note: Public Pool's early plaintext port was 21496, but the official recommended port has since migrated to 3333. Both ports coexisted for a time. Currently, 3333/13333 are the standard.
- Username = Your BTC Address: Public Pool accepts standard BTC addresses as usernames. In community tests and various mining software, Bech32 (SegWit v0) addresses starting with
bc1qoffer the best compatibility. Taproot addresses starting withbc1pmay have parsing issues with older mining software (such as early Nerd Miner firmware); it is recommended to use the latest firmware. P2PKH addresses starting with1and P2SH addresses starting with3are also supported. - Password Field is Arbitrary: Filling the Stratum password field with
xor123is fine; it serves as a protocol placeholder and does not affect verification. - Worker Suffix Optional: You can use
.workernameto distinguish between different devices, facilitating identification in multi-miner setups. If omitted, the default is 'default'.
⚠️ Frontend display of "Worker Active" alone cannot prove that block rewards will definitely belong to you—if there is a typo in the address string configured in your miner, the pool will most likely reject the connection (no frontend data). However, in extremely rare cases (where the erroneous string happens to pass the Bech32 checksum, probability approximately one in nine trillion), shares may be silently credited to a valid address not belonging to you. The frontend will still show "Worker Active," but any future block rewards will be permanently lost.
2、Independent Verification: SSH into Node to Check Public-Pool Logs
The core of independent verification lies in directly observing the runtime state of the public-pool service on your own node. When you connect to the node via SSH and execute docker logs, you see the raw operational logs of the public-pool container—confirming whether the Stratum service is listening correctly, whether your miner client has actually connected, and whether the underlying Bitcoin Core is fully synchronized and capable of providing getblocktemplate.
Prerequisites:
- The underlying Bitcoin Core must be fully synchronized (
verificationprogressclose to 1.0). - The public-pool container status must be Up.
1、🔥 Establish connection using ssh umbrel@your_node_local_IP.
2、➡️ Execute sudo docker ps | grep public-pool to confirm the container status is Up.
3、🏃 Enter sudo docker logs container_ID --tail 200 to limit output to the last 200 lines and avoid log overload.
4、❓ Filter key information using grep, focusing on two types of lines:
Stratum server is listening on port 3333—— Proves the Stratum service is active;New client ID: xxx, ip:xxx—— Proves your miner client has connected.
If your public-pool instance uses your own BTC address as the mining username to receive jobs, the full bc1 address may not necessarily appear directly in the block template log lines. What can be definitively confirmed is: "Your client is connected + Stratum service is running + Bitcoin Core is synced and can generate new block templates." Ultimately, the correctness of the reward address depends on whether the username BTC address entered in your miner configuration truly belongs to you——please verify this directly on the wallet side.
Synchronization Status Check:
Before checking logs, always execute sudo docker exec bitcoind bitcoin-cli getblockchaininfo to confirm verificationprogress is close to 1.0. If the underlying full node is still synchronizing, public-pool cannot call the getblocktemplate RPC interface to generate new work units. Miners may exhibit "normal connection but never submitting valid shares."
3、Relationship Between the Two Verification Layers
The two layers of verification form a complete cognitive chain from phenomenon to essence. Lightweight verification captures the application-layer connection status, while independent verification touches the truth of the node's runtime state. The former relies on the honesty of the pool operator's data; the latter is based on your complete control over your own node. For miners pursuing ultimate certainty, the second layer eliminates trust dependencies on third-party data sources.
| Comparison Dimension | Lightweight Verification (Frontend Login) | Independent Verification (Node Logs) |
|---|---|---|
| Verification Target | Share statistics recorded by pool server | Public-pool container runtime + Client connections + Chain sync status |
| Required Privileges | Browser read-only access | Root-level SSH access to node |
| Tamper Resistance | Low (Server data can be falsified) | High (Based on full control of local node) |
| Typical Duration | Under 30 seconds | 5 to 10 minutes |
Why is this layered architecture so important?
In TCP/IP networks, the Stratum protocol (as a plaintext or TLS-encrypted C/S protocol) faces theoretical risks of Man-in-the-Middle (MitM) hijacking. An attacker could intercept your request mid-transit, return a forged "Accepted" response, and redirect your hashrate to another address. Independently verifying that your own node's Stratum service is running normally and that your miner client has indeed connected to your node significantly reduces exposure to such risks.
Since standard Stratum V1 miners cannot automatically verify the coinbase output address, reliance on trust in the Public Pool open-source code is advised. To completely eliminate MitM tampering, ensure your miner (TinyChipHub proprietary hardware, e.g., Zyber Blanc OC) is on the same Local Area Network (LAN) as your node, or use TLS encrypted ports (4333/14333). Additionally, meticulously compare the wallet address field character-by-character in the miner configuration page to ensure no typos exist.
From an engineering perspective, the two-layer verification also resolves "eventual consistency" issues. Due to Bitcoin network block propagation delays, statistics displayed on the pool frontend may lag behind the actual node state by several blocks. Under normal conditions, a new block template is generated whenever a new block appears on the network or when there are significant changes in the memory pool. If you observe an abnormally high frequency of block template updates, it might indicate the node is undergoing a chain reorganization or experiencing a surge in mempool transaction activity.
4、Common Pitfalls
In the world of Bitcoin mining, the devil is always in the details—specifically, the binary bits. Below are high-frequency traps summarized by TinyChipHub Studio and many North American and European home miners during community exchanges. Each point stems from real-world failure cases.
- 💣 Address Format Compatibility Trap: Although Public Pool supports all standard address types,
bc1pTaproot addresses may face parsing compatibility issues with older mining software (like early Nerd Miner firmware). It is recommended to use the officially recommended latest mining software and ensure the firmware is up-to-date; prioritizebc1qfor initial configurations. - 💣 Port Occupancy Conflict: Check if the port is occupied by another process (
sudo lsof -i :3333), which prevents the Stratum service from starting. Logs will repeatedly show bind: address already in use errors. Solutions include modifying port mappings in docker-compose.yml or adjusting Tor hidden service configurations to free the port. - 💣 Firewall Blocking: If connection fails, check local firewall or router settings. For public instances, switch to port 4333 (TLS) or 14333 (PPLNS TLS) to bypass potential ISP blocking. For Umbrel local firewall issues, use
sudo ufw allow 3333to open the port. - 💣 System Time Drift: System time must be synchronized with NTP. While Bitcoin Core allows a max offset of 4200 seconds, excessive drift severely impacts peer connections; keep the deviation within a few seconds of standard time. This causes the pool to fail at generating new work units, leading to miners showing "connected" but never submitting valid shares.
🔥 The Most Critical Trap: The Ghost Miner Phenomenon.
When the BTC address entered in your miner configuration contains a typo, the actual outcome depends on the Bech32 checksum result, falling into two scenarios:
In the vast majority of cases, random character errors break the Bech32 checksum, producing an invalid address. The pool will reject the subscription or disconnect immediately upon receiving the invalid address as a username, meaning shares are never recorded—you will quickly notice the absence of frontend statistics and realize the misconfiguration.
In extreme cases, the erroneous string happens to be a valid address passing the checksum (probability approx. one in nine trillion). In this scenario, the pool accepts shares normally and credits them to that address. The frontend will display "Worker Active" as expected. Should this instance luckily find a block, the reward is sent to an address not belonging to you, resulting in permanent loss of funds, as the Bitcoin network has no "recovery" mechanism.
Best Practice: After configuration, first verify address ownership character-by-character on the wallet side. Then, observe if share statistics appear on the frontend within a reasonable timeframe as cross-validation. However, note that "frontend data" only proves the pool accepted your connection; it cannot solely prove rewards belong to you—ultimate certainty comes from verifying the address string in your miner configuration, letter by letter.
