Job Negotiation

安娜换用了 Stratum V2，却仍然从矿池接收交易列表，这并不矛盾。负责传递工作和结果的 Mining Protocol 可以在没有 Job Declaration 和 Template Distribution 的情况下运行。后者提供区块模板，Job Declaration 则处理自定义提案。安娜要自己选择，就需要把这些角色也接入流程，并使用支持它们的矿池。因此，更现代的传输方式本身，并不能说明谁在决定 Bitcoin 区块的内容。 [1] [4]

选中的付款不能把区块塞满，导致奖励交易 coinbase 无处可放。因此，模板提供方 Template Provider 必须知道需要预留多少空间。安娜一侧运行着 JDC 程序，全称为 Job Declarator Client。它取得所用矿池的要求，再用名为 CoinbaseOutputConstraints 的数据消息发送给模板提供方。预留的不仅是数据空间，还包括 sigops，也就是计入区块限额的签名验证操作。否则，后来添加的 coinbase 输出——分配资金的项目——可能使区块超出限制。自主选择交易，从一开始就要考虑整个结果是否有效。 [3]

在 Full-Template 模式中，JDC 向 JDS 发送 DeclareMiningJob。JDS 是矿池一侧或矿池信任的服务所运行的 Job Declarator Server。消息列出所选交易的标识符。如果服务器缺少某笔交易，可以通过 ProvideMissingTransactions 索取数据。这样，安娜提供了检查其选择所需的资料。确认声明与矿池随后接受自定义任务，是两个独立步骤。第一条成功消息，还不代表整个协商已经完成。 [2]

在 Coinbase-only 模式下，JDC 不披露交易集合，也不使用 DeclareMiningJob。矿池根据提交的 coinbase 估算收入。这可以对矿池隐藏安娜的选择，但本身既不能证明隐藏交易有效，也不能证明实际手续费是多少。规范明确指出了这种风险。共享的数据减少，也会改变能够进行哪些检查；模式名称本身并不保证所有奖励条件都已经得到充分证明。这种隐私保护针对挖矿过程中的草案。如果安娜挖出有效区块并向网络广播，其中的交易就会公开。 [2]

技术通信里会出现几个看起来相似的标记。JDS 分配 mining_job_token，客户端在 SetCustomMiningJob 中引用它。矿池接受任务后，会通过 SetCustomMiningJob.Success 返回自己的 job_id。令牌和 job_id 的作用不同：前者把提案协商联系起来，后者用于提交结果时标识对应工作。这类似申请编号与已批准工单的编号。把它们弄混，矿池就无法把结果归到正确的已接受任务上。 [1]

每一步都等待网络回复，会让设备无谓地停工。一旦客户端取得所需令牌和模板，就可以在 SetCustomMiningJob.Success 到来前开始乐观挖矿。找到的 shares，是按照矿池目标证明工作量的部分结果，会先保存，等到确认后再处理。任务被接受后，才能用分配的编号提交这些结果。因此，机器正在运行，并不能证明矿池已经接受或计入了这份工作。开始计算与同意为任务付酬，是不同的时点。 [1] [2]

如果安娜收到 SetCustomMiningJob.Error，或在合理时间内等不到回复，规范建议转到另一矿池，必要时独立挖矿。因此，韧性取决于可用的 fallback，也就是事先准备好的替代路径。如果软件悄悄改用拒绝她的矿池原先提供的模板，虽然能继续运行，却会丢掉安娜自己的交易选择。所以必须了解系统被拒绝时究竟会做什么。协议描述了某项能力，并不证明每个服务都支持它。 [1] [4]

安娜既想选择交易，也想继续分享矿池奖励。她的 JDC 因此必须在 coinbase 中向矿池指定的输出分配金额，以满足奖励条件。如果把部分收入转向其他地方，矿池可以按比例降低该任务的报酬。Job Declaration 并不会自动变成直接向矿工付款，也不会取消服务的记账条件。它主要改变谁能够提出区块内容；区块有效性规则与收入如何分配，仍要分别看待。 [2]