<p><a href="https://twitter.com/satofishi/status/1693114570728976540" rel="nofollow noreferrer">Wang Chun of f2pool (@satofishi) said on Twitter</a>: “We repurpose those 4 bytes to hold the stratum session data for faster reconnect.”</p>
<p>He <a href="https://twitter.com/satofishi/status/1693537663985361038" rel="nofollow noreferrer">went on to say</a>: &quot;The coinbase locktime is set to: 500000000 + 1 &lt;&lt; share_pdiff * 28800000 + host_id * 240000 + proc_id * 20000 + connection_id</p>
<p>For example, block 804186’s coinbase locktime is 0x3e9db736, which indicates the block was mined from a share which pdiff is 524288, and the share was received by pool server #13, process #10, stratum connection #3446.</p>
<p>The share_pdiff is also packed into stratum job_id, so that in case of connection lost, the client reconnects and sends us pre-disconnect works. Since the client may reconnect to a different pool server, which may not have the knowledge what the share’s pdiff was. Without this trick we may have to either discard the share or query a centralized database to determine that share’s pdiff. By encode pdiff into both the coinbase tx and job_id we can decode the pdiff from job_id and verify it against the pow without having to maintain a database of jobs sent.&quot;</p>

CC BY-SA 4.0
2023-08-21T11:07:57.173Z
Thank you @schmidty for your edit.
bordalix
CC BY-SA 4.0
2023-08-20T11:03:26.327Z
2023-08-21T11:06:44.647Z
2023-08-21T11:06:44.647Z
bordalix
<p>Some coinbase transactions have locktime values set. One such recent example is:</p>
<pre><code>{
  &quot;txid&quot;: &quot;5166cb509a5d786db33963a269ea08ff82a1c40d37d4fb828a394b0465cd5efd&quot;,
  &quot;hash&quot;: &quot;075ffc5116296983aaa8286b4fdbaac101ba891a471cb835e9c532be926a7673&quot;,
  &quot;version&quot;: 1,
  &quot;size&quot;: 415,
  &quot;vsize&quot;: 388,
  &quot;weight&quot;: 1552,
  &quot;locktime&quot;: 1026070553,
  &quot;vin&quot;: [
    {
      &quot;coinbase&quot;: &quot;030ecb0a2cfabe6d6ddc5406c4378d32bde05d3b7d966ee5a6546c116e9b920d8c8564c2cff893a9dd10000000f09f909f082f4632506f6f6c2f0000000000000000000000000000000000000000000000000000000000000000000000000500fac90200&quot;,
      &quot;txinwitness&quot;: [
        &quot;0000000000000000000000000000000000000000000000000000000000000000&quot;
      ],
      &quot;sequence&quot;: 0
    }
  ],
  &quot;vout&quot;: [
    {
    ...
</code></pre>
<p>(Its <a href="https://mempool.space/api/tx/5166cb509a5d786db33963a269ea08ff82a1c40d37d4fb828a394b0465cd5efd/hex" rel="noreferrer">rawtransaction here</a>).</p>
<p>As is apparent, the locktime is bereft of any meaning, since it is above the max block height value of 500'000'000, but with a Unix timestamp at Sun Jul 07 19:35:53 2002 UTC also set in the past.</p>
<p>What is its purpose? Are the mining pools attempting to communicate something?</p>

CC BY-SA 4.0
2021-10-30T13:25:23.240Z
This is the first time I hear about this, but perhaps it's used as an additional nonce that's easier to increment than the one in the txin?
Pieter Wuille
CC BY-SA 4.0
2022-12-31T09:03:56.980Z
Could it be a way to avoid the 101 confirmations maturity time ? Doesn't look possible but canno't figure out why they are doing that
Charles KEMPF
CC BY-SA 4.0
2023-01-17T21:51:40.797Z
Does this answer your question? [Why would a transaction have a locktime of 1987!](https://bitcoin.stackexchange.com/questions/115549/why-would-a-transaction-have-a-locktime-of-1987). P.S. I'd mark the other a duplicate of this as the other is dated later, but the other has answers that make the cause of this clearer.
RedGrittyBrick
CC BY-SA 4.0
2023-01-20T09:07:14.073Z
The answer you linked here does not answer this question. The transaction here is not a commitment transaction and its locktime is not set to 1987.
TheCharlatan
CC BY-SA 4.0
2023-05-04T12:45:19.420Z
It's possible that the locktime value was set to a specific value for a reason known only to the miner, but without more information, we can only speculate. It could be an attempt to communicate something, a form of watermarking, or simply an arbitrary choice. I recommend that you seek counsel from an F2Pool representative to respond to this query.
deyw
<mining-pools><coinbase-transaction><locktime>
Why are miners setting the locktime in coinbase transactions?
TheCharlatan
# Why are miners setting the locktime in coinbase transactions?

(Asked by: username_0 on 2021-10-30)

Some coinbase transactions have locktime values set. One such recent example is:
{
  "txid": "5166cb509a5d786db33963a269ea08ff82a1c40d37d4fb828a394b0465cd5efd",
  "hash": "075ffc5116296983aaa8286b4fdbaac101ba891a471cb835e9c532be926a7673",
  "version": 1,
  "size": 415,
  "vsize": 388,
  "weight": 1552,
  "locktime": 1026070553,
  "vin": [
    {
      "coinbase": "030ecb0a2cfabe6d6ddc5406c4378d32bde05d3b7d966ee5a6546c116e9b920d8c8564c2cff893a9dd10000000f09f909f082f4632506f6f6c2f0000000000000000000000000000000000000000000000000000000000000000000000000500fac90200",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 0
    }
  ],
  "vout": [
    {
    ...

(Its rawtransaction here).
As is apparent, the locktime is bereft of any meaning, since it is above the max block height value of 500'000'000, but with a Unix timestamp at Sun Jul 07 19:35:53 2002 UTC also set in the past.
What is its purpose? Are the mining pools attempting to communicate something?

**Tags:** mining-pools, coinbase-transaction, locktime

> **Comments:**
> **username_1**: This is the first time I hear about this, but perhaps it's used as an additional nonce that's easier to increment than the one in the txin?  
> **username_2**: Could it be a way to avoid the 101 confirmations maturity time ? Doesn't look possible but canno't figure out why they are doing that  
> **username_3**: Does this answer your question? [Why would a transaction have a locktime of 1987!](https://bitcoin.stackexchange.com/questions/115549/why-would-a-transaction-have-a-locktime-of-1987). P.S. I'd mark the other a duplicate of this as the other is dated later, but the other has answers that make the cause of this clearer.  
> **username_0**: The answer you linked here does not answer this question. The transaction here is not a commitment transaction and its locktime is not set to 1987.  
> **username_4**: It's possible that the locktime value was set to a specific value for a reason known only to the miner, but without more information, we can only speculate. It could be an attempt to communicate something, a form of watermarking, or simply an arbitrary choice. I recommend that you seek counsel from an F2Pool representative to respond to this query.  

---

## 1 answers

### Answer by username_5 on 2023-08-20. Score: 6 | Accepted answer

[Wang Chun of f2pool (@satofishi) said on Twitter](https://twitter.com/satofishi/status/1693114570728976540): “We repurpose those 4 bytes to hold the stratum session data for faster reconnect.”

He [went on to say](https://twitter.com/satofishi/status/1693537663985361038): "The coinbase locktime is set to: 500000000 + 1 << share\_pdiff \* 28800000 + host\_id \* 240000 + proc\_id \* 20000 + connection\_id

For example, block 804186’s coinbase locktime is 0x3e9db736, which indicates the block was mined from a share which pdiff is 524288, and the share was received by pool server #13, process #10, stratum connection #3446.

The share\_pdiff is also packed into stratum job\_id, so that in case of connection lost, the client reconnects and sends us pre-disconnect works. Since the client may reconnect to a different pool server, which may not have the knowledge what the share’s pdiff was. Without this trick we may have to either discard the share or query a centralized database to determine that share’s pdiff. By encode pdiff into both the coinbase tx and job\_id we can decode the pdiff from job\_id and verify it against the pow without having to maintain a database of jobs sent."

> **Comments:**
> **username_5**: Thank you @schmidty for your edit.  

---

