Several hours ago I sent the transaction 0xe9cca30f9d8d2040a3c6c5ceb6601240b0c095a47ac9117dd34e36c0d66be2f7 into Ethereum testnet. When asking a node about it, everything seems right (confirmed transaction):

> eth.getTransactionReceipt("0xe9cca30f9d8d2040a3c6c5ceb6601240b0c095a47ac9117dd34e36c0d66be2f7");
  blockHash: "0xed3c145b87b83a52c42eb9f54c02e05be0da4b0723faf82ee1237b1b599bd180",
  blockNumber: 1806280,
  contractAddress: null,
  cumulativeGasUsed: 43282,
  from: "0xbeb1c53c48f916e099f0d13d3c65f8943dd8ddd2",
  gasUsed: 22282,
  logs: [],
  root: "53f83e77cd68ccee638efcb753426238d5483bf9879086fd3e19288742515596",
  to: "0x27c042342c9ba937214117e11a4970a6145034cb",
  transactionHash: "0xe9cca30f9d8d2040a3c6c5ceb6601240b0c095a47ac9117dd34e36c0d66be2f7",
  transactionIndex: 1

Nevertheless, this transaction is not visible through etherscan explorer:


Unable to locate Transaction entry

Not sure if it has something to do with Incoming transaction confirmed but not showing in Mist wallet

Is there any reason that can explain the anomaly? Thx!


One possible explanation for the anomaly, you could be locally mining the transaction but not connected to other morden testnet peers.

The following may help if this is the case:

See: Geth - Checking Connectivity

Specifically, the following commands.

> net.listening
> net.peerCount
> admin.peers

You could also check your balance (locally) and confirm that it matches the expected results in the blockchain explorer.

> web3.fromWei(eth.getBalance('0xbeb1c53c48f916e099f0d13d3c65f8943dd8ddd2'), 'ether')

Should match the balance here.

  • 1
    This may be correct, but it would be unusual for a the local blockchain to be ahead of the true chain, since the first few blocks would take an extremely long time to mine. It could happen, with all the DoS attacks lately – Tjaden Hess Oct 25 '16 at 0:20
  • @TjadenHess true / good point. To the original poster: BokkyPooBah's post above is also very much on point / a good possibility. – Derek Tiffany Oct 25 '16 at 0:39

Actually I think the problem might be running an old version of geth, not suitable for EIP150 Hardfork. After upgrading geth from v1.4.10 to v1.4.18 everything should run smoothly again. Thx!

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.