5.0 Release feature list

Adjustments to 5.0 release

An increment in the protocol version to version 5: This will allow shareholders to vote for this specific version. We don't want to mix voting with the protocol 4 clients because they have a different switch threshold. In that sense it is a different protocol. However, in terms of the what is permitted in transactions and blocks, protocol 4 and 5 will not differ at all.

Lowering the switch threshold to 55% from its current value of 90%: 55% is the lowest percentage that we can be reasonably confident will prevent large numbers of consecutive orphan blocks as the switch occurs. While a 55% percent threshold brings higher risks of problems around the time of the switch, the risks are much smaller than the risks of substantial additional delay that the 90% threshold brings.

Upgrade alerts via data feed: We need to add the ability to alert the user to upgrade via data feed. This has the advantage of decentralising the decision to upgrade network software while not requiring shareholders to take the initiative to follow what is going on in the forums.

Default data feed providers applied upon install: Default data feeds are strong medicine for shareholder apathy. Care must be taken to preserve and foster decentralisation in network decision making and we must ensure that default data feeds don't skew decision making in the network toward any particular outcome. We can do that by asking shareholders to vote for default data feed providers as motions (one for each provider). When the code must be finalised, we tally the blockchain votes for each data provider. If data feed provider A gets 60% of the total votes and data feed provider B gets 40%, then the install process will set provider A as the default 60% of the time and provider B as the default 40% of the time. The install user interface will feature a drop down with Provider A, Provider B, None and Custom. All options will be available in every install. Only the initial selection will be determined by the combination of shareholder vote and lottery just described. Currently we have only two data feed providers, so this doesn't look like great decentralisation. But the architecture will easily accomodate many more data providers should individuals choose to create additional data feeds. This is almost sure to occur if B&C Exchange is even modestly successful.

Vote Abstention

At the request of sigmike I would like to make a modification to the B&C 5.0 specifications, which are described in the original post.

There has been discussion around adding the capability to abstain from voting when minting for a long time, going back to at least December 2014 when woodstockmerkle wrote about the possibility.

I have been wary of any solution that would require shareholders to actively and specifically vote no on a grant or motion to prevent its passage. There is, however, a limited manner in which abstentions can be employed without creating a situation where "no" voting is a necessity. Rather than set default data feed providers, I am persuaded that simply setting the default voting behavior on a new install to abstain is the best course of action to address the noise that comes from apathetic voting. We can do this with a simple check box labeled "Abstain" located to the right of the voting buttons on the Voting tab.

Blocks found by abstaining minters simply won't count when deciding whether a motion or grant has passed. Consider a scenario where 50% of blocks in a 10,000 block series have an abstention. This would mean that only 2501 blocks need to have a vote for a particular grant in order for it to pass.

We will still be including a new drop down list of data feed providers, so they will be much easier to select and configure than they are now. We just won't automatically set a default.

Other than these changes, the 5.0 release is now code complete. Hopefully the team will be able to make the changes quickly and we can release very soon.

V4.0 ratio now reaches 65%+, perhaps we lift the threshold to 60%?