[ANN][BTCS][CRYPTOVOTER LAUNCH] Bitcoin-sCrypt | in techcrunch

[Smokeasy]

Splendid work Ladies and gentlemen.
Smokeasy this is a sterling job!
Well done.

Thx Byron.

[1714019241]

1714019241

[1714019241]

1714019241

[bloods-n-cryptos]

I think now would be a good time to start discussing voting details, like parameters, questions, and stuffs.

[Smokeasy]

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.

[bloods-n-cryptos]

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.

Looking forward to discussing the voting!

[KimNam]

bitcoin scrypt is back?   moved here from cryptocointalk?

[lulla.by]

bitcoin scrypt is back?   moved here from cryptocointalk?

Seems like I already seen this

[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.

[KimNam]

White paper describing your voting protocol?

[Smokeasy]

White paper describing your voting protocol?

The white paper describing the CryptoVoter shareholder-style blockchain voting system can be found here:  http://bit.ly/wpcvoter

When 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

[KimNam]

White paper describing your voting protocol?

The white paper describing the CryptoVoter shareholder-style blockchain voting system can be found here:  http://bit.ly/wpcvoter

When 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

ok ty

[bloods-n-cryptos]

When will the voting block deadline be posted?

[Smokeasy]

When will the voting block deadline be posted?

I will post voting parameters shortly for feedback and discussion from you guys.

[bloods-n-cryptos]

When will the voting block deadline be posted?

I will post voting parameters shortly for feedback and discussion from you guys.

Looking forward to getting the discussion going on bitcointalk.

[Smokeasy]

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

[bloods-n-cryptos]

• VOTING DATE DEADLINE:  Is the voting date deadline confusing?  Is there a better way?

Good questions.  I'll try to give you my feedback on most of them after work.  Here is my answer to the first question.

No I don't think the voting date deadline thing is confusing.  We should just focus on the voting block deadline mostly.  The date thing is just a recommendation right?

More feedback after work.  Thanks.

[KimNam]

Interesting voting.  I think I understand it but have question.

I don't think it can but has your team evaluated if the voting can be manipulated like signature voting?

[KimNam]

Also, I agree with the idea but I think most people would want one person = one vote instead of your system?

[Smokeasy]

Interesting voting.  I think I understand it but have question.

I don't think it can but has your team evaluated if the voting can be manipulated like signature voting?

It cannot be manipulated like signature voting because voting coins must be confirmed in a voting address at the voting block deadline.  Since one coin cannot be in two places at the same time, users cannot manipulate voting.

Make sense?

[Smokeasy]

Also, I agree with the idea but I think most people would want one person = one vote instead of your system?

tbh, after learning how it works most people support the idea of one coin = one vote instead of one person = one vote.

We chose the one coin = one vote for two important reasons:
1.  We believe that those who have a bigger stake in the outcome should have a bigger voice in any decision, just like shareholders in a corporation.
2.  Creating a one person = one vote voting system defeats the purpose and technology behind decentralization because a trusted-third-party is required to make sure that one person get one, and only one, vote, which would inherently centralize the voting.

[KimNam]

Also, I agree with the idea but I think most people would want one person = one vote instead of your system?

tbh, after learning how it works most people support the idea of one coin = one vote instead of one person = one vote.

We chose the one coin = one vote for two important reasons:
1.  We believe that those who have a bigger stake in the outcome should have a bigger voice in any decision, just like shareholders in a corporation.
2.  Creating a one person = one vote voting system defeats the purpose and technology behind decentralization because a trusted-third-party is required to make sure that one person get one, and only one, vote, which would inherently centralize the voting.

Thanks for answering questions.

I see you guys make the Bitcoin Scrypt votes before the Bitcoin votes.  The vote about changing Bitcoin Scrypt coin name before Bitcoin could be good for Bitcoin Scrypt.

I just sent you PM.