14

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?

Improve this question
5
  • 16
    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
    Commented Oct 30, 2021 at 13:25
  • 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
    Commented Dec 31, 2022 at 9:03
  • Does this answer your question? 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
    Commented Jan 17, 2023 at 21:51
  • 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
    Commented Jan 20, 2023 at 9:07
  • 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
    Commented May 4, 2023 at 12:45

1 Answer 1

Reset to default
6

Wang Chun of f2pool (@satofishi) said on Twitter: “We repurpose those 4 bytes to hold the stratum session data for faster reconnect.”

He went on to say: "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."

Improve this answer
1
  • 1
    Thank you @schmidty for your edit.
    – bordalix
    Commented Aug 21, 2023 at 11:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.