MultiChain Developer Q&A - Recent questions tagged mining-diversity

mining-turnover Vs. mining-diversity

Thu, 06 Feb 2020 15:32:25 +0000

I want to use round robin instead of POW with some control to avoid some problems that Multichain solve like freezing but I am confused to use mining-diversity or mining-turnover or both specially I am confused about mining-turnover as I couldn't find clear specific definition specifically for intermediate values.

What is mining diversity?

Sat, 16 Mar 2019 06:40:41 +0000

Thanks for your reply.Can u help me with the above question.?

As miners donot get any incentives the what is the term 'mining diversity'.I already gone through the multichain docs but if would be more appreciated if u explain it clearly

What is the role of the Publisher in Data Streams ?

Sun, 03 Feb 2019 13:48:30 +0000

I have been using data streams in my Project and i have noticed that each item has a field called " Publishers " .

1. My question is, what exactly is the role of the publisher in a data stream ?

2. Why must every item, that is published in a data stream, needs a publisher specified for it ?

3. Is it possible for one item to have multiple publishers ? If so, how would that be useful ?

4, Do publishers take part in mining the transactions, which occur when an item is published on a data stream ?

Questions about customizing/extending multichain

Fri, 06 Apr 2018 12:51:15 +0000

Hi,

We're planning to run a custom blockchain with Multichain as a base except we want to modify the API (add our own API calls, have some custom permission handling, etc). I have two questions:

1. Would it be possible to restrict that the only nodes to connect to our blockchain would be running our exact same custom API? Our concern is that since we would open source our code, in theory someone could compile/build their own copy and bypass any custom permissions we implement.

2. We understand there is a blockchain parameter mining-diversity that controls how many miner confirmations are needed to validate. Would it be possible to customize/modify multichain such that this value can be modified after initialization? Or some other way to adjust the required number of confirmations at some point in the future? (Unfortunately I do not have a justification/use case for this scenario at the moment, it is a client request that we are following up on)

Thanks!

Multichain Cluster stops mining

Thu, 07 Sep 2017 00:38:12 +0000

We discovered an issue yesterday whereby are test cluster stopped mining. It had been running for about a week without issue beforehand. After a number of failed attempts to get the nodes mining again we cleared it down and started it up fresh, after a short space of time the issue occurred again.

Our working theory at the minute is:

Our automated tests create new addresses/keys per run and were assigning these new addresses mining permission. The only mining parameter we had changed on our setup was admin-consensus-mine which was set to 0. Is it possible that all these additional addresses/keys on the node were affecting the rules governing mining, specifically related to the mining-diversity setting?

I have now tuned this down to zero and keeping an eye on the newly created cluster.

A couple of questions:

Do you think this was the issue, and if so then there's probably some guidance required for the proper configuration of your cluster with respect to the mining config vs nodes etc?

Secondly, how could we have recovered from this. In the end we cleared down the cluster because we couldn't get it mining. All transactions were just sitting in the mempool. If this happened in a production environment, blowing it away is not really an option :)

Assuming the issue was caused by these additional mining permissions, would revoking them have recovered the cluster?

If this is a misconfiguration issue rather than a bug/problem, some sort of log or message from the nodes would have been really useful given the amount of time we spent trying to resolve the issue.

If you think this shouldn't have been an issue, have you any other suggestions as to what the problem might have been. I backed up the volume of one of the nodes and should be able to start it up again to investigate further?

Marty

Number of active nodes for mining a block

Mon, 26 Jun 2017 12:06:35 +0000

I have 3 miner nodes and mining-diversity = 0.5, mining-turnover = 0.0. In this case minimum 2 miners should be active to mine a block, but this is working some time with 2 miners being active and some time it is't working even though 2 miners are active. If 3rd miner becomes active then mining the block working. I want to know the proper setting of mining-diversity, mining-turnover (and any other run time parameters ) value which will mine the block if there are at least 2 miners active.

What constitutes an "active miner"?

Sun, 08 Jan 2017 00:46:59 +0000

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.