Job Negotiation is an arrangement between a miner and a pool about a custom mining job. Stratum V2 defines how mining equipment and pools communicate. Job Declaration Protocol is its part for custom proposals and works alongside template and job distribution. Its purpose is to allow miners to select transactions while the pool continues accounting for work and paying rewards. What matters is the actual setup, not merely the connection’s name.
Anna switches her connection to Stratum V2 but still receives the transaction list from the pool. There is no contradiction. The Mining Protocol, which carries work and results, can operate without Job Declaration or Template Distribution. The latter supplies block templates; Job Declaration handles custom proposals. Anna needs those roles in the setup as well, together with a supporting pool. A more modern transport alone therefore says nothing about who chooses the contents of a block on the Bitcoin network. [1] [4]
The selected payments must not fill the block so completely that its reward transaction, coinbase, no longer fits. The Template Provider must therefore know how much room to reserve. A program called JDC, short for Job Declarator Client, runs on Anna’s side. It obtains the requirements of the pools being used and sends them to the Template Provider in a data message called CoinbaseOutputConstraints. Reservations cover both data space and sigops, signature-checking operations counted toward the block’s limit. Otherwise, added coinbase outputs, the entries assigning funds, could push the block beyond its limits. A custom transaction selection must account for the validity of the whole result from the start. [3]
In Full-Template mode, JDC sends DeclareMiningJob to JDS, the Job Declarator Server on the pool side or at a service trusted by the pool. It lists the identifiers of the selected transactions. If the server lacks one of those transactions, it can request the data through ProvideMissingTransactions. Anna thus shares information that allows her selection to be checked. Acknowledging the declaration and the pool’s subsequent acceptance of the custom job are two separate steps. The first successful message does not complete the whole arrangement. [2]
In Coinbase-only mode, JDC does not reveal the transaction set and DeclareMiningJob is not used. The pool estimates revenue from the supplied coinbase. This keeps Anna’s selection private from the pool, but does not itself prove the hidden transactions’ validity or their actual fees. The specification explicitly describes this risk. Sharing less information also changes what can be checked; the mode’s name alone does not guarantee that all reward conditions have been properly demonstrated. This privacy concerns the proposal during mining. If Anna finds a valid block and broadcasts it to the network, its transactions become visible. [2]
Several similar-looking references appear in the technical exchange. JDS assigns mining_job_token, which the client references in SetCustomMiningJob. When the pool accepts the job, it returns SetCustomMiningJob.Success with its own job_id. The token and job_id have different roles: the former connects the proposal process, while the latter identifies work when results are submitted. Think of an application number and an approved work-order number. Confusing them would prevent the pool from associating a result with the correct accepted job. [1]
Waiting for every network exchange would needlessly delay equipment. Once the client has the necessary token and template, it can start optimistic mining before SetCustomMiningJob.Success. The resulting shares, partial results demonstrating work under the pool’s target, are buffered until acknowledgement. After job acceptance they can be sent with the assigned identifier. A running machine therefore does not yet prove that the pool has accepted or credited that work. Starting calculations and agreeing to reward the job are separate moments. [1] [2]
If Anna receives SetCustomMiningJob.Error or no response within a reasonable time, the specification recommends another pool, or solo mining. Resilience therefore depends on a working fallback, a prepared alternative route. If the software quietly switched to the rejecting pool’s original template, it might keep running but would lose Anna’s own selection. It matters what the system actually does on rejection. A capability described in a protocol is not evidence that every service supports it. [1] [4]
Anna wants to select transactions while retaining pooled rewards. Her JDC must therefore assign value to the pool’s designated coinbase output to qualify for those rewards. If she directs some revenue elsewhere, the pool may reduce the reward for that job proportionally. Job Declaration does not create an automatic direct payout to the miner or remove the service’s accounting conditions. It chiefly changes who can propose block contents; block-validity rules and the way income is shared must be assessed separately. [2]
For the clearest picture, read this entry together with Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. The reverse links also lead from Stratum V2, Mining Pool Centralization.