6

When I start the mining process it can take over an hour before the first block is mined. Once the mining has started each new block is very quick.

My mac is the only node on a private chain so it shouldn't need to synchronise before starting. I tried deleting all of the chain data and starting again from block 0. Does anyone know of a way to speed the process up?

|improve this question
  • 1
    It also slows down a lot when mining blocks with transactions on them but im not sure if that is related – Joe Mar 30 '17 at 16:15
  • 2
    The first problems seems related to network difficulty, try lowering the difficulty field in the genesis block. Default geth will mine one block each 15 seconds on average, you can edit the source code to use a faster generation time, but it will pollute your blockchain with empty blocks. See this article for faster mining blog.coinfabrik.com/…. – Ismael Mar 30 '17 at 19:23
  • 1
    @Ismael It is only the first block and the blocks with transactions that are slow. Wouldnt every block be slow if the difficulty was too high? – Joe Mar 31 '17 at 9:16
  • 1
    The difficulty will adjust to 1 block each 15 seconds, if the first block takes a long time, the difficulty will drop automatically. – Ismael Mar 31 '17 at 15:05
  • 2
    @0xcaff I've said in my first comment to try lowering the difficulty in the genesis block. But it is odd that the slowdown also happens with transactions (perhaps transactions are too complex?). So my suggestion was to directly edit the difficult function in geth to make it constant. – Ismael Jun 14 '17 at 15:32
4

This might be due to an ongoing issue with go-ethereum.

What you might observe

  • The DAGs were generated (ie. geth is done with the Generating DAG in progress outputs).
  • The mining has officially started (ie. geth prints Commit new mining work)
  • Nothing else happens. If you restart geth again, it prints Commit new mining work and seems to wait for ever.

A Workaround

  • Remove the DAGs (in C:\Users\[yourself]\AppData\Ethash or ~/.ethash).
  • Restart the node
  • Connect to the node with geth attach, then make sure the miner is on with miner.start()

This issue is not well documented, it is more a set of observations and empirical workaround from various users (including me). So you should use this answer at last resort.

|improve this answer
2

Open task manager and look at what is bottlenecking the mining process.

If the disk is the bottleneck, the miner is probably generating the DAG. See jeff's answer for more.

If the CPU or Memory is the bottleneck, your initial mining difficulty is set too high. Change it in the genesis block:

{
    "config": {
        "chainId": 15,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip158Block": 0
    },
    "difficulty": "200000000", // <- this number here
    "gasLimit": "2100000",
    "alloc": {
        "7df9a875a174b3bc565e6424a0050ebc1b2d1d82": { "balance": "300000" },
        "f41c74c9ae680c1aa78f42e5647a62f353b7bdde": { "balance": "400000" }
    }
}

If the difficulty is still too high, you will have to lower the difficulty of the client by building form source. For geth, you can do this by editing params/protocol_params.go and changing the DifficultyBoundDivisor, GenesisDifficulty and MinimumDifficulty values.

|improve this answer
1

Your miner is probably generating the DAG. See this answer for a detailed explanation.

|improve this answer
1

Try to close the heavy applications like Excel, Winword, Outlook etc. Once mining start you can you start your applications.

|improve this answer
1

Mining was taking lot of time for me to start the private ethereum network on my mac book and i have found that we need to delete 2 folders and files from Mac for Ethereum to behave as fresh start-

  1. Deleting the content of "data directory - datadir" in my case it was chaindata because of below command used fro genesis initialisation. $ ./geth --datadir=./chaindata/ init ./genesis.json

Go this path in your mac and delete geth and keystore folders recursively : $ cd /Users/YOUR USER NAME/Library/Application Support/Ethereum Wallet/binaries/Geth/unpacked/chaindata/ Deleting Command : $ rm -rf geth , keystore/

  1. Delete ".ethash" folder which is located in below location in my mac $ cd /Users/YOUR USER NAME $ rm -rf .ethash

Please let me know if it helps.
Cheers raky

|improve this answer
1

This may happen if you are using a machine with low RAM. As the difficulty for the block 0 maybe set to a high number. You can try the below points to decrease the difficulty and then start the private network. P.S. The below points will drastically increase you block mining speed.

There are 2 ways to do this:

  • Change the value of difficulty parameter in genesis.json file to a small number(preferably set it to 0). You can refer to this example genesis file

{ "config": { "chainId": 1994, "homesteadBlock": 0, "eip155Block": 0, "eip158Block": 0, "byzantiumBlock": 0 }, "difficulty": "0x0", //difficulty set to zero in hexadecimal format "gasLimit": "0x8000000", "alloc": { "9a963d0eefeb62678d8efb48561c81e51c552797": { "balance": "9606938044258990275541962092341162602522202993782792835301376" }, "30f28686aef33adbfbc13797b1d9f5a2f2759f56": { "balance": "9606938044258990275541962092341162602522202993782792835301376" } } }

Problem with this method is that when the block number increases, the difficulty also starts increasing at a high rate. So, to tackle that problem refer to the below part.

  • Try creating your own version of ethereum(takes about few minutes)

You can reduce the rate of block difficulty increament by making some changes in the consensus code of go-ethereum. Open consensus.go which resides at consensus/ethash/consensus.go and search for the below line.

return CalcDifficulty(chain.Config(), time, parent)

Now replace the above line with the below one.

return big.NewInt(1).

Now build the go-ethereum using make geth command.

I strongly recommend you to go through this article for much detailed implementation of the above process.

|improve this answer

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.