Resolve Miner.start () return to null__ ether Square

Below I listed three kinds of solutions, the front two are some two big guy to try out, the third kind is I cast out.

First kind of solution

Reprinted from Http://mp.weixin.qq.com/s/AB9vj1EzOgWT7JyryfQhDg problem scene

Recently, the technical Group of friends often asked such a problem, the environment has been set up, Geth node also successfully started, but why when the implementation of the Miner.start () method did not dig ore, return null.

In fact, not only these friends, I was in the start-up of the latest node to dig mine also encountered similar problems. Today we are going to analyze some of the possible causes of this problem. whether to set miner address

Before starting the node to dig the mine, you need to see if the account exists in the current node, you can execute the following command to see if there is an account under the current node.

>personal.listaccounts

["0xc040cbd8a189d36f580fa83c2ffe3a26fb3e6a7e", "0XE0D1DE6C934049FE4847B64BECFF5885BDB83FA4"]

When the confirmation account already exists, you can set the Etherbase. Check out the following Coinbase accounts first:

>eth.coinbase

"0xc040cbd8a189d36f580fa83c2ffe3a26fb3e6a7e"

Through the above command, you can see the Coinbase account address, that is, check the address above to find the first address.

To perform the setup miner address:

>miner.setetherbase (Eth.coinbase)

True

You can also perform the following command to set:

>miner.setetherbase (Eth.accounts[0])

True

You can then perform a mining command to see if the problem is resolved. node false Alarm

In another case, the Miner.start () command has been successfully executed, except that the node returns NULL. If it is dev mode, you can use Eth.blocknumber to see if the block height increases. node version problem

I installed the geth-1.7.3 version of the node, in the dev environment to verify the discovery, when the execution of Miner.start (), return null. But in fact miner has been executed, except that it waits for you to send a transaction before it generates a new chunk.  That is, the execution of Miner.start (), which has been waiting, which is to send a deal, and then view the block height found has been added to the piece. (pay attention to this sentence, my blind source)

The second type of solution

Reproduced from: https://blog.csdn.net/wo541075754/article/details/79260040

The previous article is also a collection of online solutions, but in the process of practice found that can not effectively solve the problem, only to send transactions will automatically dig mine . Therefore, for this problem and a large number of reading access to the data, and finally find the reason and solution. Reasons and Solutions

This problem occurs because of a new parameter entry in –dev mode after the Geth version is updated:

--dev               ephemeral proof-of-authority network with a pre-funded developer account, mining enabled
--dev.period Value Block  period to developer mode (0 = mine only if transaction pending) (default:0)

We first look at the above two parameters, –dev is our commonly used parameters, in the previous version we only use –dev and then execute Miner.start () can be dug, but in the later version, when we will find that only send a transaction will dig a block.

The cause of this problem is the addition of the –dev.period value configuration entry. The default value for this configuration is 0, which means that only transactions with pending will be dug.

Understand the meaning of this parameter, solve the problem is very simple answer, the previous –dev parameters are still used, and then add –dev.period 1, note that the parameter value is 1, not the default of 0.

Then restart the node, and then perform the mining, regardless of whether the return is null, after execution, regardless of the view log or execution Eth.blocknumber will find that the block is constantly increasing.

The third type of solution

Feel my inability to solve the problem of Miner.start () put back null, but let account[0] have a certain ether, easy to test with the back, digging not to dig mine does not matter,

First unlock accounts[0] and accounts[1]

$ personal.unlockaccount (Eth.accounts[0])

$ personal.unlockaccount (eth.accounts[1])

To launch a 5ether deal

$ amount = Web3.towei (5, ' ether ')

$ eth.sendtransaction ({from:eth.accounts[0],to:eth.accounts[1],value:amount})

This will show the failure

Error:insufficient funds for gas * price + value
At web3.js:3143:20
At web3.js:6347:15
At web3.js:5081:36
At <anonymous>:1:1

All right, keep on launching a 0ether deal.

$ amount = Web3.towei (0, ' ether ')

$ eth.sendtransaction ({from:eth.accounts[0],to:eth.accounts[1],value:amount})

Then it succeeds, succeeds, succeeds, and the previous deal succeeds.

The screenshot is served

Today, I tried again, and found that my mining rate was too low, resulting in a long transaction to be packaged, an average of 10 minutes to dig a mine (...) Is there some kind of mystical connection between my private chain and Bitcoin, the following map

Executive Eth.gethashrate (), found only 0, this is what the situation, Google simple check, there is said to be Ubuntu problem, there is said to be the GPU mining problem, have a moment to see what is the situation, know what the problem of the big guy can leave a message tell me.

See here, I suggest, try another computer.

To be continued.