15

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
["0x699ec6d49641e59f65ba4bf72c52628059301e64"]
> var foo = eth.accounts[0];
undefined
> miner.setEtherbase(foo);
true
> miner.start(2);
true

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);
0

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.

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

3 Answers 3

8

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.

1
  • 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. Feb 14, 2018 at 21:33
4

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.

2

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 and acknowledge you have read our privacy policy.

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