15

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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