Some kind of centralised checkpointing at stage of development could save us a lot of troubles.
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.
That hits the nail on the head!
…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.
1 evil minters: to understand what I mean by that, read this: [Draft] BKS grant to bring protocol 4.0 votes above 90%
1 Like
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.
2 Likes
Thank you! I fix it!
Did you already try? Did it work?
I did as you advised. now there is synchronization. like all good. Wallet*.dat file is replace.
1 Like
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.
What is the window? The normal 10k or something bigger?
We have 3.
How easy will it be to do a revote, say once a year? It would be a softfork, correct?
No voting? Starting voting and citing the last-100-block-percentage would give a sense of due process.
1 Like
Thought likewise. To which extent does it make sense to submit a motion for this. Did we submit a motion for 4.0,1?
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.
7 Likes
How does this effect #3?
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?
So the release that will enable trading is nearly code complete? Is the project still actively looking for another core developer?
We will still use default data feed providers, but only for upgrade alerts, which is not a type of voting. The abstention only applies to voting.
Sorry for the confusion. At least in terms of the switch date, this upcoming 5.0 is a protocol change versus the 4.x releases. We needed to increment the protocol number to separate the protocol voting properly.
This means the features that were formerly expected in version 5 will now be re-lableled as version 6. Nothing changed about that release except its name.
We are no longer looking for another core developer. @Eleven is getting a great deal of work done.
3 Likes
That’s great to hear.