一、先明确“最初”的讨论范围
“最初挖矿”既可能指历史上的早期实现，也可能指初次了解挖矿技术。两者不能混为一谈：早期软件接口不等于适合后续系统的方案，包含专用硬件的工作流程也不能直接代表比特币诞生时的配置。这里主要解释入门所需的基础机制，并说明旧接口的局限。
二、哈希计算不是解密
NIST《安全哈希标准》规定了生成消息摘要的哈希算法，摘要可用于检测消息是否发生变化。这是理解哈希功能的基础，但该标准本身不是比特币挖矿协议，也不规定矿池如何分配报酬。
理解挖矿时，应将“生成摘要”与“满足区块接受条件”分开。能够计算哈希，不代表已经找到有效区块；挖矿也不是通过解密来获得他人的密钥或账户权限。
三、理解区块头与搜索空间
Bitcoin Developer Guides 的挖矿说明将主要流程概括为：根据交易等信息构造区块头，反复计算哈希，找到符合目标阈值的结果后提交区块。区块头中的 nonce 可被修改；需要扩展搜索空间时，还可调整 coinbase 交易中的额外 nonce，并更新相关默克尔根。
这里的 coinbase 交易指区块中的特殊交易，不是交易平台名称。修改交易内容后，不能继续沿用与旧内容对应的默克尔根。技术理解的重点是保持交易、默克尔根与区块头之间的一致性，而非只关注计算次数。
四、不能把旧接口当作通用方案
开发者指南将 getwork 标记为已弃用接口，同时介绍了 getblocktemplate 与 Stratum 等工作信息传递方式。阅读历史教程时，应先辨认接口及其适用的软件环境，不应因为示例曾经可用，就认定它仍能直接兼容其他系统。
接口之间的区别不只是名称，还涉及工作信息的粒度、交易选择能力和更新方式。讨论 Stratum 时也应限定具体版本及实现，避免将某一种流程的特点推广到所有同名协议。
五、矿池份额不等于有效区块
矿池中的 share 是按矿池所设条件提交的工作记录。满足份额条件的结果，不一定满足比特币网络的出块条件。因此，份额提交成功与区块被网络接受，是两个不同层级的事件。
常见误区是把份额数量直接理解为出块数量，或者据此推断固定报酬。份额统计首先服务于工作量核算，不能脱离具体规则解释，更不能据此作出收益承诺。
六、持续计算还要配合任务更新
算力持续运行，并不意味着始终在处理有效的新任务。理解完整流程时，还应关注新区块出现后的工作更新、网络通信以及提交结果的状态。
遇到提交异常，应区分通信中断、工作信息过时和结果未满足要求等不同情况，不能仅凭“设备正在计算”判断流程正常。入门阶段先厘清这些状态，比单独比较计算速度更有助于理解挖矿系统。