We think it's a good time to start the discussion on voting parameters on Bitcointalk so we can get some feedback on proposed voting rules for the upcoming votes. Below, please find our initial thoughts on certain voting parameters for community feedback. We are actively soliciting community opinions on the voting process so feel free to ask anything. VOTING PARAMETERS:VOTING DATE DEADLINE- Description: The Voting Date Deadline is the estimated date that the votes for a particular question must be cast.
- Commentary: The Voting Date Deadline is just an estimate of when the Voting Block Deadline will occur and is not a guarantee of when voting will actually end for that question. The Voting Block Deadline overrides the Voting Date Deadline if they conflict.
- Questions: Is this confusing? Is there a better way?
VOTING BLOCK DEADLINE:- Description: The Voting Block Deadline is the specific blockheight deadline that all votes must be cast by for a particular question and only voting addresses with non-zero balances at that designated blockheight will be counted. Non-zero voting address balances before or after the blockheight deadline will not count for voting to eliminate double-voting (e.g., double-spending).
- Comments: The voting block deadline will be announced 48 hours before the estimated voting deadline date.
- Questions: Is 48 hours enough time before an estimated voting date deadline to announce the block? How best to estimate voting block deadline when mining hashes vary so much?
VOTING MAJORITY- Description: Unless stated otherwise, voting will be decided based on which answer choice receives more than >50% of all cast votes.
- Comments: In the event no answer choice receives more than 50% of the vote, then the top two answer choices will have a subsequent run off election to get to >50%
- Questions: Should we consider an instant run-off system instead of having a separate run-off election if no answer gets >50% support?
META-VOTES- Description: For major votes, we plan on holding initial meta-votes to decide whether or not to vote on the actual issue itself
- Comments: We think breaking down major votes into initial meta-votes will give users a better chance to investigate and participate, if/when a meta-vote passes rather than expecting them to educate themselves enough before an initial vote.
- Questions: Any suggestions or comments on a better way to proceed for major votes besides using meta-votes?
FREQUENCY OF VOTES- Description: For Bitcoin-sCrypt, the first two-votes will be two weeks apart, but subsequent Bitcoin-sCrypt votes will be held approximately once-per-month
- Comments: Initially we're having the first two votes so close for two reasons: (1) to (hopefully) build some momentum early on with voting and (2) we wanted to give Bitcoin-core users an opportunity to try out CryptoVoter's shareholder-style blockchain voting with Bitcoin-sCrypt one week before the first Bitcoin-core blockchain meta-vote on whether to vote on increasing the maximum blocksize.
- Questions: Is once-a-month voting too frequent or not frequent enough? Should Bitcoin-sCrypt coordinate with Bitcoin-core re voting?
COMMUNITY-BASED VOTING QUESTIONS- Description: A methodology for allowing users to propose questions to be voted on
- Comments: The only way to truly achieve decentralized development is to allow users to propose questions re development for the community to vote on. We want the process to be fair and public. Initially, we're thinking to have users post potential questions in the forums which we can decide to adopt as future voting questions. However, in time we want to create a way to allow anyone to post the question on the website with a way for the community to decide which questions get voted on next
- Questions: Any other suggestions on a process or methodology to allow users to submit questions for the community to vote on (instead of giving developers sole discretion on what questions are presented to the community)?
REQUIRING +n CONFIRMATIONS- Description: We are considering adding a requirement that voting coins must have at least +n confirmations at the voting address in order to count towards voting. The first vote scheduled for Oct 2, 2015, will not have a +n confirmations requirement
- Comments: Currently, with no +n confirmations requirement, voting is essentially cost-free which may incentivize vote-buying/vote borrowing because users who do not care about a particular voting outcome can sell their votes without ever giving up control of their coins. In addition to that problem, with no +n confirmations requirement third-party unauthorized fiduciaries like exchanges, mining pools, escrows, etc..., can vote on issues using coins they control but technically do not own. By adding a sufficiently high +n confirmations requirement for votes to count, voting coins would be voluntarily locked up and unable to be used for required +n confirmations which could work to disincentivize these stated problems because of the cost of voluntarily not being able to use coins for required confirmation time.
- Questions: After the first vote, should we require +n confirmations in order for votes to count? If so, how many +n confirmations should be required to address the problems mentioned?
HERE ARE THE AFOREMENTIONED QUESTIONS LIST AGAIN:- VOTING DATE DEADLINE: Is the voting date deadline confusing? Is there a better way?
- VOTING BLOCK DEADLINE: Is 48 hours enough time before an estimated voting date deadline to announce the block? How best to estimate voting block deadline when mining hashes vary so much?
- VOTING MAJORITY DEFINITION: Should we consider an instant run-off system instead of having a separate run-off election if no answer gets >50% support?
- META-VOTES: Any suggestions or comments on a better way to proceed for major votes besides using meta-votes?
- VOTING FREQUENCY: Is once-a-month voting too frequent or not frequent enough? Should Bitcoin-sCrypt coordinate with Bitcoin-core re voting?
- COMMUNITY-BASED VOTING QUESTIONS: Any suggestions on a process or methodology to allow users to submit questions for the community to vote on (instead of giving developers sole discretion on what questions are presented to the community)?
- REQUIRING +N CONFIRMATIONS: After the first vote, should we require +n confirmations in order for votes to count? If so, how many +n confirmations should be required to address the problems mentioned above?
Please review this information and give us any feedback on the proposed questions or any other feedback or questions or criticisms as well. We will do our best to respond. Thx, Smokeasy |
|
|
|
When will the voting block deadline be posted?
I will post voting parameters shortly for feedback and discussion from you guys. |
|
|
|
White paper describing your voting protocol?
The white paper describing the CryptoVoter shareholder-style blockchain voting system can be found here: http://bit.ly/wpcvoterWhen we came up with the idea in January 2014 and initially called it "Vanity Voting" because we used vanity addresses to vote. You can also see the alpha-test vote results on the http://BTCS-voter.com website. Check it out and let me know if you have any questions. Thx, Smokeasy |
|
|
|
bitcoin scrypt is back? moved here from cryptocointalk?
The official forum is still hosted at CryptoCoinTalk but now that I've taken over development completely, I'm ending the previous dev's boycott of Bitcointalk. |
|
|
|
I think now would be a good time to start discussing voting details, like parameters, questions, and stuffs.
Good idea. Depending on the reception we get here, may begin voting discussions here. |
|
|
|
|
The hash rate has been jumping around a bit as of late but Bitcoin-scrypt (BTCS) can still be mined profitably with gpu but that will probably change once the CryptoVoter blockchain voting starts.
|
|
|
|
|
can someone kindly point me to where I can find hash rates and prices for the latest scrypt asics out there?
|
|
|
|
Splendid work Ladies and gentlemen. Smokeasy this is a sterling job! Well done.  Thx Byron. |
|
|
|
I think it should be changed because I thinks the scrypt part is too generic also.
But the logo may need to be changed anyway if the name change vote is successful.
How hard is a logo contest to setup if the vote does pass? I think we would be using the voting system for the logo contest vote too, right?
Yes we would decide the logo contest using the voting system. I'll look into options for a potential logo contest. |
|
|
|
Hi all, Maybe we can have a discussion about the first vote which will be at 2 oktober. What would be the pros and cons if we would change the logo or not? I personally think it would be good thing if we change it to something more universal, because the 'scrypt' part of this coin would be able to change in the future. Maybe beter to change now before we get big  Cheers, Mike Changing the logo and distributing the changes wouldn't be that hard but timing would have to be after the name change vote. |
|
|
|
Sorry if this was asked but I missed it or if its somehow obvious and I just dont get it, but what is keeping me from
#1 vote
#2 send coins to newly generated address
#3 vote again
#4 goto #1
Vote weight is calculated proportional to current balance of the address associated with the vote. So if you move your coins the vote will be revoked.
TechCrunch published an article a couple of days expanding on the CryptoVoter voting proposal. http://techcrunch.com/2015/09/21/a-solution-to-bitcoins-governance-problem/ |
|
|
|
The 2-4-8 route is still based on guesswork, though. I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases. That would also give the benefit of not being a temporary kludge than needs to be altered later. BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.
The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB). It wouldn't be a problem if there were smaller increases (or decreases) more frequently. For example, there's no point doubling to 4MB if we're only going to end up averaging 2.5MB for a while. The biggest challenge with changing the rules is getting the whole ecosystem to agree on them. We all individually have our pet theories as to how we would do it properly, but the actual solution needs to literally "resonate" with Bitcoin as a whole as it's supposed to serve the interests of that single whole. Different parties in the system have their own considerations for themselves as the internal environment is highly competitive. In a recent days I have come to realize that Bitcoin only needs to change if something threatens it as a whole. In other words, if there is a system that can do its job better and as of right now there is no such system. To put it simply, there are multiple ways to change the rules and only one way to keep them. The latter always wins if there is much disagreement as it has the most gravity. Fair point, but in the course of trying to find a solution that the whole (or at least a significant majority) of the ecosystem can agree on, how do we prepare for the inevitable accusations of "populist tactics" from that group? The ones who are probably going to disagree just for the sake of being disagreeable because they believe that maintaining a hostile environment is the best route to enforcing ideals that would inevitably lead to an exclusive chain that the average person won't be able to transact on: Decentralization increases if contentious forks are met with hostility: forked coins could immediately be sold, businesses who transact in them could be ostracized, individuals who support them should be discredited. The simple fact is, there is no solution that won't come under fire simply for not being of primary benefit to a small, but decidedly noisy, minority. Shareholder-style voting where votes are weighed based on ownership percentages could address the issues of a noisy minority. http://techcrunch.com/2015/09/21/a-solution-to-bitcoins-governance-problem/ |
|
|
|
Before the first Bitcoin-core vote on October 23, CryptoVoter will hold two initial votes on the Bitcoin-sCrypt altcoin blockchain on October 2 and October 16 to give interested parties a chance to try voting beforehand. https://bitcointalk.org/index.php?topic=1188271.0 |
|
|
|
Thank you! Smokeasy for this great coin and voting client. You and your team have done an amazing job. Well done.
Thanks guys. Close to the finish line. Need to close out strong. Thanks for all the support. |
|
|
|
well done! I really like this one and have been mining it a while back ago. Now, I don't have any coins... I guess I'll start to mine some more.
Can still be mined by GPU's too. As of now it can, but I suspect that will change once word spreads its the first cryptovoter vote coin. Then I think the scrypt asics will start jumping on board. |
|
|
|
I think you guys should try to get on more exchanges than just C-Cex.
Actually, we are working on getting on a few of the major exchanges before the big vote. |
|
|
|
not premine and not any bounty in this coin This is a very old coin, I don't think there was any premined and Smokeasy took over the development without any incentives. I'm glad he didn't give up, btw I still have all my coins  As mentioned in the OP, we refused to do any prefunding of vaporware with an ICO or premine. As a result it took longer to develop but we finished with an actual working product. Now ready for the next stage. |
|
|
|
Good job smoke! Way to stick to the plan man.
Thanks for sticking around bloods-n-cryptos. Glad we got this working. |
|
|
|
Well done smokeasy!
Nice to see you didn`t give up on BTCS, thats a lot of perseverance you have.
With the new voting system we can finally give the coin what it deserves.
Cheers,
Mike
Thx for the support Mike! |
|
|
|
|
Show Posts
