I've got a private test network running as per this article. In particular my difficulty is set to 0x400; the entire genesis file I'm using can be seen here.

Mining with geth does not seem to work at all.

Here's what I've tried to do. First a fresh blockchain and account:

vagrant@debian-jessie:~$ mkdir stackexchange-example-chain
vagrant@debian-jessie:~$ geth --genesis local_genesis.json \
  --datadir stackexchange-example-chain \
  --networkid 9991 --nodiscover --maxpeers 0 account new

Then after dealing with that, booting up the console:

vagrant@debian-jessie:~$ geth --genesis local_genesis.json \
  --datadir stackexchange-example-chain \
  --networkid 9991 --nodiscover --maxpeers 0 console

And then what I understand to be the standard mining setup:

> eth.accounts
> var foo = eth.accounts[0];
> miner.setEtherbase(foo);
> miner.start(2);

The logs report that generating the DAG for epoch 0 finishes in ~1 second, and then the miner seems to hang. The longest I've let it run is about 15 minutes, but at the difficulty I've specified I understand that I should be mining plenty in far less time than that. If I check miner.hashrate at any point I just get a bizarre new BigNumber() not a number: [object Object] error.

I've also tried wiping the .ethash directory and generating a new DAG from scratch. Same result.

After stopping with miner.stop(2), a getBalance call verifies that no ether have been mined:

> eth.getBalance(foo);

If I call eth.getBlock('pending', true) I receive the following information (you can see the entire log/console session output in this gist):

  difficulty: 131072,
  extraData: "0xd783010400844765746887676f312e352e31856c696e7578",
  gasLimit: 268173313,
  gasUsed: 0,
  hash: null,
  logsBloom: null,
  miner: null,
  nonce: null,
  number: 1,
  parentHash: "0x522fe03765d5834422cd7cfc88c435f33bcd13d7a4c71cd8eaf321a8b3dd8ea3",
  receiptRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 536,
  stateRoot: "0x2fa7b359e63faf5af52846537e67053ffd96d2fd33877704192c9c3e6e6266b9",
  timestamp: 1455530923,
  totalDifficulty: 0,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []

Notice that the reported difficulty is much higher than what I've specified in my genesis file; 131072, whereas I assume it would be 1024. Maybe this isn't representing the same difficulty, though. Later on the totalDifficulty is reported as 0, perplexingly.

Does anyone have any insight into what could be going wrong here?

It seems like this is the same problem encountered in this question.

  • 1
    This sounds pretty much like a bug and you could try to get official support at the github repository by creating a ticket. – Afr Feb 29 '16 at 8:59
  • Yeah, that looks to be the case. There is an existing issue there already. – jtobin Feb 29 '16 at 9:12

As mentioned in the comments, this appears to be due to a bug.

Rebooting my VM seems to have worked around the issue in the meantime.

  • the bug was closed for being outdated and as of geth v1.7.3-stable-4bb3c89d I had to wait 28 minutes before the first block was mined and had to wait an additional 5 minutes before the second block and after that it was fast, so just be patient. It may be due to my having the private network down for several days as restarting only caused an initial 1 minute delay. – user3338098 Feb 14 '18 at 21:33

I had a similar issue. If you are running in a virtual machine. Make sure you allocate enough ram memory. I used 800MB initially and mining did not work (Hash rate was very low). Allocated 2GB of memory and it worked fine.


We had a very similar problem. Updating Geth to the latest version and deleting and rebuilding the DAG appears to have fixed the problem

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.