确认 Public Pool 地址在线不能只看网页亮没亮，要到节点侧验证。前端显示 "Worker Active" 只是矿池服务端单方面声明它收到了来自该地址的份额提交——但这只是网页从服务端拉取的统计数据，你无法从浏览器本身验证这个声明的真伪。真正的 Stratum V1 握手发生在你的TCH矿机与 stratum+tcp://public-pool.io:3333（或对应模式端口）之间，前端不参与握手过程。
1、轻量验证：用 BTC 地址登录 Public Pool 查看
轻量验证的本质是一次快速的应用层状态确认。当你把 BTC 地址填进 Public Pool.io 前端时，前端会从矿池服务端拉取该地址关联的统计数据；而真正的 Stratum V1 握手发生在你的矿机与 public-pool.io 的 Stratum 服务之间——矿机主动向服务端发起连接、订阅任务、提交 shares。
很多人常犯的错误是只检查浏览器能不能加载页面，却忽略了底层 TCP 端口的连通性，结果矿机空转了十几个小时都没察觉。
根据 Public Pool 官方提供的接入信息，各模式连接参数如下：
| 挖矿模式 | 连接地址 | 端口 | 协议类型 |
|---|---|---|---|
| Solo 模式 | stratum+tcp://public-pool.io | 3333 | TCP |
| Solo + TLS 加密 | stratum+tls://public-pool.io | 4333 | TLS 加密 |
| PPLNS 模式 | stratum+tcp://public-pool.io | 13333 | TCP |
| PPLNS + TLS | stratum+tls://public-pool.io | 14333 | TLS 加密 |
📌 小提示：Public Pool 早期明文端口为 21496，后来官方将推荐端口迁移到 3333，两个端口曾并存一段时间。当前以 3333/13333 为准。
- 用户名 = 你的 BTC 地址：Public Pool 接受标准 BTC 地址作为用户名。社区与各类挖矿软件实测中，以
bc1q开头的 Bech32（SegWit v0）地址兼容性最好；bc1p开头的 Taproot 地址在部分旧版挖矿软件（如早期 Nerd Miner 固件）上可能存在解析问题，建议使用最新固件。以1开头的 P2PKH、3开头的 P2SH 同样可用。 - 密码字段随意填：Stratum 密码栏填
x或123均可，这只是协议占位符，不影响验证结果。 - Worker 后缀可选：可以用
.workername区分不同设备，方便在多台矿机场景下识别，不填则默认为 default。
⚠️ 前端显示 Worker Active 不能单独证明出块奖励一定会归你——如果你的矿机配置里地址字符串拼写错误，绝大多数情况下矿池会拒绝连接（前端无数据）；但在极罕见的情况下（错误字符串恰好通过 Bech32 校验和，概率 约 九万亿分之一），shares 会被静默记录到一个不属于你的有效地址下，前端照样显示 Worker Active，一旦出块奖励将永久丢失。
2、独立验证：SSH 进节点查 Public-Pool 日志
独立验证的核心在于直接观测你自己节点上 public-pool 服务的运行状态。当你通过 SSH 连接到节点并执行 docker logs 时，你看到的是 public-pool 容器的一手运行日志——它能确认 Stratum 服务是否正常监听、你的矿机客户端是否真的连了进来、底层 Bitcoin Core 是否已完成同步并可对外提供 getblocktemplate。
前置条件：
- 底层 Bitcoin Core 必须完全同步（
verificationprogress接近 1.0）。 - public-pool 容器状态为 Up。
1、🔥 使用 ssh umbrel@你的节点局域网IP 建立连接。
2、➡️ 执行 sudo docker ps | grep public-pool，确认容器状态为 Up。
3、🏃 输入 sudo docker logs 容器ID --tail 200，将输出限制在过去 200 行以内，避免日志信息过载。
4、❓ 用 grep 过滤关键信息，重点找两类行：
Stratum server is listening on port 3333—— 证明 Stratum 服务已起来；New client ID: xxx, ip:xxx—— 证明你的矿机客户端已经连入。
如果你的 public-pool 实例是用你自己的 BTC 地址作为挖矿用户名接收任务的，日志中不一定会直接打印完整的 bc1 地址到 block template 行；能确定性确认的是"你的客户端已连接 + Stratum 服务在跑 + Bitcoin Core 已同步可生成新块模板"。最终奖励地址的正确性，本质上取决于你在矿机配置里填的用户名 BTC 地址是否真实归属于你——这一点请直接在钱包侧核对。
同步状态核查：
在执行日志核查前，务必执行 sudo docker exec bitcoind bitcoin-cli getblockchaininfo 确认 verificationprogress 接近 1.0。如果底层全节点还在同步中，public-pool 无法调用 getblocktemplate RPC 接口生成新的工作单元，矿机会出现"连接正常但永远提交不了有效份额"的现象。
3、两层验证的关系
两层验证构成了从现象到本质的完整认知链条。轻量验证捕捉的是应用层的连接状态，而独立验证触及的是节点运行态的真相。前者依赖矿池运营方数据的诚实性，后者基于你对自己节点的完全控制。对于追求极致确定性的矿工，第二层验证能消除对第三方数据来源的信任依赖。
| 对比维度 | 轻量验证（前端登录） | 独立验证（节点日志） |
|---|---|---|
| 验证对象 | 矿池服务端记录的 shares 统计 | public-pool 容器运行态 + 客户端连接 + 链同步状态 |
| 所需权限 | 浏览器只读访问 | 节点 Root 级 SSH 权限 |
| 抗欺骗性 | 较低（服务端数据可被伪造） | 较高（基于对本机节点的完全控制） |
| 典型耗时 | 30 秒以内 | 5 到 10 分钟 |
为什么这种分层架构如此重要？
在 TCP/IP 网络中，Stratum 协议（作为明文或 TLS 加密的 C/S 协议）存在被中间人劫持的理论风险。攻击者可能在传输层拦截你的请求，返回伪造的 "Accepted" 响应，同时将算力重定向到他人地址。通过独立验证确认你自己的节点上 Stratum 服务在正常运行、矿机客户端确实连入了你的节点，可以大幅降低对这种风险的暴露面。
由于标准 Stratum V1 矿机无法自动验证 coinbase 输出地址，建议依赖对 Public Pool 开源代码的信任。若要彻底杜绝中间人篡改，请确保你的矿机(TinyChipHub自研打造，Zyber Blanc OC)与节点处于同一局域网内，或使用 TLS 加密端口（4333/14333），并在矿机配置页面反复逐字符比对钱包地址栏，确保无拼写错误。
从工程角度看，两层验证还解决了"异步一致性"问题。由于比特币网络的区块传播延迟，矿池前端显示的统计信息可能会比节点实际状态滞后数个区块。正常情况下，每当网络出现新区块或内存池有显著变化时，都会触发新的 block template 生成。如果发现 block template 更新频率异常升高，可能是节点正在经历链重组，也可能是 mempool 交易活跃度骤增。
4、几个容易踩的坑
在比特币挖矿的世界里，魔鬼永远藏在细节的二进制位中。以下是TinyChipHub工作室、许多北美、欧洲家庭矿工在社区交流中总结出的高频陷阱，每一条背后都有真实的翻车案例。
- 💣 地址格式兼容性坑：虽然 Public Pool 支持所有标准地址类型，但
bc1p开头的 Taproot 地址在部分旧版挖矿软件（如早期 Nerd Miner 固件）上可能存在解析兼容性问题。建议使用官方推荐的最新挖矿软件，并确保固件为最新版本；首次配置优先选用bc1q。 - 💣 端口占用冲突：检查端口是否被其他进程占用（
sudo lsof -i :3333），导致 Stratum 服务启动失败。日志中会反复出现 bind: address already in use 错误。解决方法是在 docker-compose.yml 中修改端口映射，或调整 Tor 隐藏服务配置释放端口。 - 💣 防火墙拦截：如果无法连接，可能需要检查本地防火墙或路由器设置。公网实例可改用 4333（TLS）或 14333（PPLNS TLS）端口绕过可能的运营商屏蔽；若是 Umbrel 本机防火墙问题，可通过
sudo ufw allow 3333开放端口。 - 💣 系统时间漂移：系统时间需与 NTP 保持同步。Bitcoin Core 默认最大允许偏移为 4200 秒，但偏差过大会严重影响对等连接，建议控制在与标准时间相差数秒以内。这会导致矿池无法生成新的工作单元，矿机显示"连接正常"但永远提交不了有效份额。
🔥 最致命的坑：幽灵矿工现象。
当你在矿机配置中填写的 BTC 地址存在拼写错误时，实际后果取决于 Bech32 校验和的结果，分为两种情况：
绝大多数情况下，随机的字符错漏会破坏 Bech32 校验和，产生无效地址。矿池在收到无效地址作为用户名时会直接拒绝订阅或断开连接，shares 根本不会被记录——你会很快发现前端没有任何统计数据，从而察觉配置有误。
极端情况下，错误字符串恰好是一个校验和有效的地址（概率约 九万亿分之一）。此时矿池会正常接受 shares 并记录到该地址名下，前端也会如期显示 Worker Active。一旦该实例幸运出块，区块奖励将发送至这个不属于你的地址，资金永久丢失，比特币网络不存在「找回」机制。
最佳实践：配置完成后，先在钱包侧逐字符核对地址归属；随后观察前端是否在合理时间内出现 shares 统计作为交叉验证。但请注意，"前端有数据"只能证明矿池接受了你的连接，不能单独证明奖励一定归你——最终确定性仍然来自你对矿机配置中地址字符串的逐字确认。
