This should be no push and rather a pull scheme.
Nobody has the duty to inform BKS holders.
They have the duty to stay informed!
BKS is no investment that can be used for minting without following development.
If BKS holders didn’t update within that time frame and didn’t voice concerns for making the next step now (enable e.g. asset & signer voting), then I don’t know how it shall work in the future.
Partially dispossessing apathetic BKS holders (who still mint with old clients) to limit the damage for the non-apathetic BKS holders might be necessary for the future success of BCE.
BKS holders who care need to be protected as well!
If the votes for protocol 4.0 don’t increase soon, someone might draft a motion (followed by grants) or a grant (with an appropriate frame work) to sort this out.
Some of these changes such as the upgrade alerts and default data feeds have been talked about by Jordan before, so they’re not exactly new ideas. This is the first time I’ve heard him reprioritizing them though.
While I hope it doesn’t come to this, if it did, it would surely wake shareholders up and let people know:
That we’re serious about getting this exchange up and running correctly.
That there will be serious consequences for shareholders who don’t pay attention, mint, vote or upgrade on time.
It would make people think twice about becoming a shareholder if they’re not completely serious. It needs to be made known that becoming a shareholder is not like owning other simple cryptocoins. It brings with it serious responsibilities.
The fate of the entire organization and its future revenue potential depends on the active participation of shareholders and their daily decisions and voting habits. We can’t allow non-serious shareholders to bring down our organization before it’s even begun.
Actually, I think an argument can be made that it is in the best interest of the business and its future to weed these people out now rather than later. I’m not advocating for it yet, but I think it is a legit argument. We need to do everything in our power to protect B&C Exchange and ensure that only serious and active business minded shareholders make up the organization.
Tend to agree as a temporary measure, as in this stage of early development the protocol upgrade is not really a choice the shareholders have. It is the developers’ direction so it doesn’t make a lot of sense to find consensus in a democratic way.
Almost no one takes the 50% voters against the protocol upgrade seriously anyway because no reasons have been communicated to do so.
Agree with the poster about not rushing into something that would overcomplicate things though. However time to market provides some pressure in moving on.
Maybe when BKS was sold there should be a warning in bold, “You pay to buy voting rights. Use it or risk losing it.” Still I feel your pain. I lost interest in BTS because it changed often and changed big. Stakeholders vote with their feet when the community over-played their hands. We shouldn’t rush the big changes.
According to how many blocks my shares have found in the last 6.3 days and the percentage of my shares in total supply, there are 38% shareholders minting. If 47% of them are voting for 4.0, then 20% of all shareholders are minting but not voting for 4.0. If we don’t mobilze some of them we never reach 90%.
Therefore I think 30 days into releasing 4.0 and not getting nearly enough YES vote yet getting no NO voice for the protocol in the forum, we should send a message to the purchase contact addresses. We should also post it on the BKS exchange and withdraw/deposit pages at CCEDK. In this message we explain 1. the situation where apathetic shareholders are endangering the development and competitiveness of B&C, and 2. that 60 days into the release a 30-day voting will start for so-and-so serious action.
The security of the dominant data feeds will be a serious issue if they are auto-installed.
In the long term I think some kind of incentive should be put in place to encourage voting. The networks does it for processing txs in the forms of block mining/minting rewards. Why not do it for voting if voting is so vital? The simplest way is just increading mintng reward (so voting YES or NO both gets rewarded) either permanently or when high% consensus is needed.
…try to get rid of what endangers the success of B&C Exchange!
Limit the power of apathetic minters by increasing the power of active minters.
Try to get a feeling how much of this is caused by evil minters1.
This looks like trouble with the blockchain fikes or the wallet files.
The easiest way to test this is by renaming the application data folder to get a fresh start.
As you are running windows, the application data for BCExchange should be located at %appdata%\Bcexchange.
Open a Windows explorer and rename that folder.
Don’t delete it!
Btw. do you have backups of your wallet files or your BKS private keys?
After having renamed it, start bcexchange.exe again.
After reviewing the comments about my proposal its apparent it has good support. I will direct the development team to begin implementing it immediately. I will report back soon who is playing what role in readying the release. There are a few questions that remain about exactly how the default data feeds will work in terms of the UI that I will work on resolving.
I will also start a thread with a proposal on the particulars of how to have an election of default data providers very soon.
I gather this is perceived as too radical, although it would have several benefits (with regard to waking shareholders and unveiling evil minters).
Am I right?
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.
Will shareholders who abstain not receive an alert to upgrade? Also, what kind of alert was decided upon to include in the client?
Edit: Also, does this mean there is no longer any point in voting for default data feed providers? From what I understand, abstain will be the default option, but shareholders will still have the ability to easily select a data feed from the list or input their own votes. How will this list be ordered? Is it a random list or still based on the voting taking place for feed providers?
