What constitutes an "active miner"?

+2 votes

The params include a setting for `mining-diversity` that is based on the number of "active miners", and the white paper states...

A value of 1 ensures that every permitted miner is included in the rotation, whereas 0 represents no restriction at all. In general, higher values are safer, but a value too close to 1 can cause the blockchain to freeze up if some miners become inactive.

... and in a footnote hints at a possible heartbeat feature as a means of identifying miners that have gone inactive.  However, I've not found anything in the documentation to suggest that this heartbeat has (yet) been added, or in lieu of it, what currently distinguishes an active miner from an inactive miner.

My questions specifically pertain to a block chain with `anyone-can-(connect,send,receive,mine)=true`, but I suspect they are at least somewhat relevant to other configurations as well.  So....

1) How does multichain currently deal with nodes that connect, mine a bit, and then drop off never to return? When, if ever, would they no longer be considered "active" as it pertains to `mining-diversity`?

2) How might this change (if at all) with the beta release and ultimately the "genesis" ;-) release?

Thanks for the great work so far!  I'm really excited about the potential this offers.

asked Jan 7, 2017 by jsgarvin
edited Jan 8, 2017 by jsgarvin

1 Answer

+1 vote

Rather than "active miners", it should say "permissioned miners" and currently there is no heartbeat checking. So you need to ensure that at least (mining-diversity * number-of-permissioned-miners) miners are active on the network to allow the block creation process to continue. We don't expect this to change before the 1.0 release.

However if a blockchain is set to anyone-can-mine=true, then mining diversity is irrelevant, anyone can mine a block at any time, and there isn't the kind of active miner notion that you were thinking of.

answered Jan 9, 2017 by MultiChain
Is there any news on this one?
At the moment I am stuck with anyone-can-mine=true since it is a too big management overhead to track permissions of nodes and if some nodes left the network

In the worst case, some nodes dropping (intentionally!?) can stop the whole chain until you discovered what permissions to withdraw for the mining diversity to work again.
If anyone-can-mine=true then the mining diversity is not applied at all, i.e. anyone can mine a block at any time, independent of when they last mined a block. So your chain will function just fine, so long as every node behaves, even if some nodes drop off the network. This is fine for a PoC but is not recommended for a safe long-term deployment.
Maybe I was not clear. :-)
I wrote "I am stuck with a-c-m=true". I would rather like to use a-c-m=false but then there is the problem that you have to carefully check if nodes drop off the network and if these are too many your chain will stop working.
OK, so why not use anyone-can-mine=false and a low value for mining-diversity? Then your network will continue to function just fine even if most of the miners disconnect. If you also set mining-turnover low, you'll also minimize the number of forks that take place, so you'll get the best of both worlds.
...