误区一：矿机在破解密码
NIST的FIPS 180-4介绍了用于生成消息摘要的哈希算法，摘要可用于检测消息是否发生变化。比特币开发者指南则描述了矿机改变区块头相关数据、计算哈希并检查目标条件的过程。两者帮助厘清一个概念：挖矿是在寻找满足条件的计算结果，并非恢复密码或解密交易。
因此，教程中的“解题”只是一种通俗比喻。理解这一点，才能避免把矿机的重复尝试误认为具有破解账户的能力。
误区二：算力高就能按时出块
算力描述单位时间内进行哈希尝试的能力，不能直接转换成某次出块的确定时间。更多尝试意味着更多机会，但机会与结果之间仍有随机性。
这一区分适用于理解独立挖矿与矿池协作：多人共同参与可以改变贡献统计和分配方式，却不能把随机发现区块变成固定排期。教程若承诺固定时间必定出块，就混淆了概率与保证。
误区三：提交份额就是挖到区块
比特币开发者指南区分了矿池接受的份额与满足网络要求的区块。矿池通常采用较宽松的目标记录贡献，只有其中满足网络目标的结果才具备出块所需的工作量证明条件。
所以，“份额已接受”应理解为一次贡献记录，不能直接解释为链上新增了一个区块。比较份额数量时，也需要考虑份额难度，不能脱离条件只看计数。
误区四：难度与目标值同方向变化
目标值可以理解为哈希结果需要满足的数值门槛：门槛越低，符合条件的结果越少，难度越高。阅读教程时，应特别留意“目标更低”与“难度更低”的差别。
如果示例把两者混用，后续有关份额频率或计算次数的解释也可能出现偏差。判断这类表述，可以回到“允许通过的结果是否变少”这一基本问题。
误区五：旧教程可以直接套用
开发者指南将getwork描述为已弃用接口，并介绍了getblocktemplate和Stratum等工作信息传递方式。教程中的软件版本、协议与矿池环境，是理解其步骤的必要条件。
常见问题是：看到Stratum名称，是否就能推断所有实现能力相同？不能。有关交易信息获取或区块构建权限的描述，需要限定到具体协议版本与实现；仅凭协议名称，无法确认某个设备或服务的全部能力。