3

I have been calling the HTTP method getrawtransaction for a while now to retrieve raw transactions. It used to be, until recently, that I would get the time field with every transaction. However, in the last few days, I noticed that this field is no longer present with some transactions. What happened with this field?

Here is an example that does have the time field/value: /usr/local/bin/bitcoin-cli getrawtransaction b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9 1

{
  "result":{
    "hex":"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4b03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000ffffffff01b11d0096000000001976a914740ecaf436d5867903c722d783fc994c25a29b1588ac00000000",
    "txid":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "hash":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "size":160,
    "vsize":160,
    "version":1,
    "locktime":0,
    "vin":[
      {
        "coinbase":"03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000",
        "sequence":4294967295
      }
    ],
    "vout":[
      {
        "value":25.16590001,
        "n":0,
        "scriptPubKey":{
          "asm":"OP_DUP OP_HASH160 740ecaf436d5867903c722d783fc994c25a29b15 OP_EQUALVERIFY OP_CHECKSIG",
          "hex":"76a914740ecaf436d5867903c722d783fc994c25a29b1588ac",
          "reqSigs":1,
          "type":"pubkeyhash",
          "addresses":[
            "1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9"
          ]
        }
      }
    ],
    "blockhash":"000000000000003d8ec00e2cbaf8090697b1598abe1e209960e55f0884d6044e",
    "confirmations":10,
    "time":1375585378,
    "blocktime":1375585378
  },
  "id":"bitcoin"
}

Here is an example that does not have the time field/value: /usr/local/bin/bitcoin-cli getrawtransaction 0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78 1.

{
  "result": {
    "hex": "010000000153af347ad5e3c28296b7fc833a02612dbf9a5b76752133b18fd51a532803556c010000006a473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebffeffffff0292cf032f070000001976a914df01a3394df97f114943a8e37ada789ea6d7bef788ac00e1f505000000001976a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac1f020700",
    "txid": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "hash": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "size": 225,
    "vsize": 225,
    "version": 1,
    "locktime": 459295,
    "vin": [
      {
        "txid": "6c550328531ad58fb1332175765b9abf2d61023a83fcb79682c2e3d57a34af53",
        "vout": 1,
        "scriptSig": {
          "asm": "3044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a[ALL] 03628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf",
          "hex": "473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf"
        },
        "sequence": 4294967294
      }
    ],
    "vout": [
      {
        "value": 308.5354997,
        "n": 0,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 df01a3394df97f114943a8e37ada789ea6d7bef7 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a914df01a3394df97f114943a8e37ada789ea6d7bef788ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "1ML9eZVM3NTLvM25w4eYfWLQC9gHwRuBJb"
          ]
        }
      },
      {
        "value": 1,
        "n": 1,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 1e5e089913ff694d2f3f3b8ed1ec1e24bdc311c4 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "13mZvKjZ3TtzfL7z4EqsG5sMNWayzjNHtY"
          ]
        }
      }
    ]
  },
  "error": null,
  "id": "bitcoin"
}

I noticed that this is happening for newer and incoming bitcoin transactions, but not older ones. One key difference between the two JSON output is that the transaction with time and blocktime field/value also has confirmations and blockhash. The way I am getting these bitcoin transactions is that I listen to the zmq port, and once a transaction's hash comes through, I then call the HTTP method getrawtransaction to decode the hash. I do notice that if I wait a while or keep trying to call getrawtransaction (e.g. press the up arrow key + enter multiple times over a duration of a few seconds), then the transaction JSON returned eventually does have the time field/value populated.

I am speculating, at this point, that these transactions that have no time associated with them are unconfirmed? Is this understanding correct?

If my understanding is correct, that some transactions do not have a time associated with them because they are unconfirmed, when they do become confirmed, are they rebroadcasted through the network (e.g. via zmq) so that I have another chance to get them?

Please note, I am not trying to create or manipulate data, just simply listen to incoming new transactions and parse them. One of my logic centers around the time field, and since I've noticed not all transactions have this field, that code "breaks" (since the assumption is that all decoded transactions will have such a field/value).

1 Answer 1

2

I am speculating, at this point, that these transactions that have no time associated with them are unconfirmed? Is this understanding correct?

Yes. The Bitcoin.org Developer Reference explains:

enter image description here

The reason for this is that transaction themselves don't contain a time field, so the only times that can be used are either (1) when the node first received the transaction or (2) the time field from a block that includes the transaction.

Bitcoin Core does keep track of #1 but it doesn't display it in the getrawtransaction RPC output. If you need it, you can get it from the getrawmempool RPC (try calling that RPC with the parameter true). Note that the time can change if a transaction is evicted from the mempool (due to age or low fees) and then later re-added.

1
  • 1
    You can also use getmempoolentry <txid> since 0.13.0, I think. Commented Mar 28, 2017 at 19: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.