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": [
      "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?

  • 15
    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? 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 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. Jan 17 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. Jan 20 at 9:07

1 Answer 1


The purpose of the locktime in a coinbase transaction is to prevent the transaction from being added to the blockchain until a certain point in time or block height. In this example, the locktime value is set above the maximum block height of 500,000,000, making it impossible for the transaction to be added to the blockchain based on block height. Additionally, the Unix timestamp is set in the past, so it would not be able to be added based on time either. This suggests that the locktime value is not being used for its intended purpose in this transaction, and it is possible that the mining pool that created this transaction may be using the locktime field to communicate something else or simply not using it correctly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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