Luke Dashjr

Luke Dashjr 在 GitHub 上使用 luke-jr 这个名字。GitHub 保存源代码、修改提议及其历史；他的个人页面链接到 Bitcoin Knots、挖矿程序 BFGMiner 等项目。不过，个人页面不是所有贡献者的完整传记，也不代表其中的工作都由他独自完成。具体代码变更和规范的作者记录，才是更准确的依据。下面的例子围绕几个实际问题展开：如何向矿工分配工作，如何提前发现错误，以及如何判断一项提案是否真正得到使用。 [1]

挖矿是在准备好的区块上反复进行计算，直到结果满足所要求的难度。但在此之前，必须先组织好区块内容。Dashjr 编写的 BIP 22 描述了 getblocktemplate 接口，程序可以通过它获得拟议区块的结构，包括交易。收到的因此不必只是用于哈希计算的一小段区块头；程序可以自行组装区块，并在允许的范围内修改。就像拿到整项工作的资料，而不只是一个孤立步骤。最终区块仍须遵守有效性规则。 [2]

假设一笔交易花费了同一个拟议区块中另一笔交易创建的输出，那么前一笔交易也必须包含在内。BIP 22 的 depends 字段记录这种依赖关系。字段缺失表示依赖关系未知，程序不能据此断定不存在依赖。未提供的手续费信息或 sigops 也一样；sigops 是计入区块限制的签名检查操作数。没有信息不等于数值为零。这个看似细小的区别，可以避免矿工因为误读输入资料而组装出无效区块。 [2]

Dashjr 的 BIP 23 为汇集矿工工作的矿池扩展了上述接口。可选的 proposal 模式允许矿工把准备好的区块交给服务器检查，但不检查工作量证明。这样，在耗费算力寻找合适结果之前，就有机会发现内容问题。得到肯定答复，只说明提议符合该服务器的规则。所需的工作量证明尚未找到，其他节点也尚未完成判断。预检查通过，并不意味着新区块已经挖出。 [3]

另一项工作涉及规则变更的启用。Shaolin Fry 和 Luke Dashjr 编写的 BIP 8 用区块高度，也就是区块在链上的位置，来确定各个阶段。lockinontimeout 参数决定最后一个周期是否在规定条件下要求矿工发出信号，以锁定未来的启用。LOCKED_IN 不等于 ACTIVE：前者在这一机制中确保稍后的状态转换，后者才开始执行新规则。它类似于确定生效时间与真正到达那个时间之间的区别。仅仅写出提案，不会让整个网络自动切换。 [4]

Bitcoin Knots 用于运行自己的节点，即下载并完整验证区块和交易的计算机。文档说明它会整合 Bitcoin Core 的开发成果，也可以加入其他修改；软件还可以包含钱包和图形界面。本次审阅时，官网将 Dashjr 列为主要维护者。这意味着负责某个软件项目，并不意味着可以命令整个网络采用新规则。因此，选择软件时应阅读各个版本的功能与设置，而不是假定两个程序始终表现一致。 [5] [6]

下载 Bitcoin Knots 时，需要确认文件是否来自预期的发布者。官网建议验证 OpenPGP 签名，并从相互独立的来源核对公钥。公钥用于验证数字签名，但首先要确认它属于谁。签名有效且公钥身份经过正确核实，可以证明文件来源以及被签名的数据未遭修改，却不能保证程序没有缺陷。确认来源、审查代码和决定软件配置，是不同的工作。 [6]

Dashjr 还编写了关于提案准备和发布流程的 BIP 2。如今，Murch 编写的 BIP 3 已取代它。新文档明确指出：一个已经发布的 BIP，本身并不代表 Bitcoin 社区的共识，也不构成普遍的实施建议。提案可能停留在纸面上，可能被某个软件采用，也可能最终改变参与者共同执行的规则。分配编号并不会启用任何规则。因此，看到新 BIP 的消息时，还应问：谁实现了它，它是否真的在被使用？ [7] [8]