Voting for block size increase proposals

[teukon]

BIP101 - Increase to 8 MB on January 11, 2016, and double the limit every two years (Bitcoin XT)

Might I suggest:
BIP101 - Continuously raise the limit from 8MB on January 11, 2016 so that the limit is doubled every two years (Bitcoin XT).

"double the limit every two years" makes it sound like the limit will stay at 8MB for two years and then jump suddenly to 16MB.

[1714853231]

1714853231

[1714853231]

1714853231

[1714853231]

1714853231

[1714853231]

1714853231

[nLockTime]

What makes you think the information collected from the poll will be an accurate reflection of the will of the community?

Only votes with proof-of-stake signature will be taken into account. All signatures will be verified and published here.

I think we should not imposing a minimum turnout threshold. Many people are not sufficiently competent, therefore those who won't take an active part in the poll most likely just have no definite opinion. However we must make voting as much convenient as possible, and anyone who willing to vote should have the abilty to vote anonymously.

"double the limit every two years" makes it sound like the limit will stay at 8MB for two years and then jump suddenly to 16MB.

Description was taken from here: https://en.bitcoin.it/wiki/Block_size_limit_controversy#BIP_101
Clarification added: will increase linearly based on the block's timestamp, and shall be 8GB after 20 years

[Carlton Banks]

What makes you think the information collected from the poll will be an accurate reflection of the will of the community?

Only votes with proof-of-stake signature will be taken into account. All signatures will be verified and published here.

I think we should not imposing a minimum turnout threshold. Many people are not sufficiently competent, therefore those who won't take an active part in the poll most likely just have no definite opinion. However we must make voting as much convenient as possible, and anyone who willing to vote should have the abilty to vote anonymously.

That's incredibly prone to manipulation. This sort of thing would be dangerous if it was binding, thankfully not the case.

[nLockTime]

That's incredibly prone to manipulation. This sort of thing would be dangerous if it was binding, thankfully not the case.

What kind of manipulation?

[Carlton Banks]

That's incredibly prone to manipulation. This sort of thing would be dangerous if it was binding, thankfully not the case.

What kind of manipulation?

People falsifying their identity in order to subvert the vote.

[nLockTime]

Carlton Banks, this is a proof-of-stake voting. People signing messages with their addresses with bitcoins. What's the identity you're talking about?

[Carlton Banks]

Carlton Banks, this is a proof-of-stake voting. People signing messages with their addresses with bitcoins. What's the identity you're talking about?

Sorry, I misunderstood.


Don't Coinwallet.eu get slightly too many votes then... or am I still misunderstanding?

[funkenstein]

Aha,

  I like your interface!  
  You may have seen our offering in the space:  http://coin-vote.com

  There is another service coming on line soon:  cryptovoter.com


  These all have similar ideas in terms of "proof of stake" voting, we should all make it possible to dump the votes so anyone can verify them.  It would be wise of us to choose a precise wording if we wish to combine results.  

  I'm not yet convinced a coin-vote or stake vote will influence the future of bitcoin on this issue, however I am glad to see that we have the option to look at what the biggest coin holders are saying.  

  I expect nothing to come of these votes unless big holders sign some signatures from cold storage, to the tune of 100kBTC in votes or more.


  Cheers --   funkenstein the dwarf

  

[nLockTime]

Don't Coinwallet.eu get slightly too many votes then... or am I still misunderstanding?

I'm not sure, but most likely users know their addresses and can see that their votes have been stolen.
Additionally, users have the ability to specify the number of bitcoins stored on various services. If these bitcoins have crucial importance for decision-making then an email notification with a suggestion to vote will be sent to their owners.

we should all make it possible to dump the votes so anyone can verify them

Without any doubt. Also we can add the option to search a message and its signature by an address.

It would be wise of us to choose a precise wording if we wish to combine results

I tried to choose short, user-friendly and easy to parse syntax. But we can also combine the results with different statement formats.

[nLockTime]

Anonymous voting

Alternatively you can vote by sending 0.00000001 BTC to a special Bitcoin Address*. In that case the transaction must have no more than two outputs: one to address for voting, and one back to your initial address (known as change). Weight of the vote will be calculated proportional to this "change".

Bitcoin address for voting must be created in according to the following rules:
1 - Perform RIPEMD-160 hashing on the vote message
2 - Add version byte (0x00) in front of RIPEMD-160 hash
3 - Perform SHA-256 hash on the extended RIPEMD-160 result
4 - Perform SHA-256 hash on the result of the previous SHA-256 hash
5 - Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
6 - Add the 4 checksum bytes from stage 5 at the end of extended RIPEMD-160 hash from stage 2. This is the 25-byte binary Bitcoin Address
7 - Convert the result from a byte string into a base58 string using Base58Check encoding. This is the most commonly used Bitcoin Address format

vote message syntax:

Code:

#BITCOINVOTE {+|-}{BIP id} -{BIP id} -{BIP id} ...

where

- available BIP identifiers are: BIP100, BIP101, BIP102, BIP103, BIP8MB, BIPCBBSRA, BIPRosenfeld, BIPUpal
- only first BIP may begin with '+'
- BIPs starting with '-' must be listed in alphabetical order
- all BIPs must be separated by single spaces
- all letters must be upper case

In addition, the following special messages are acceptable:

Code:

#BITCOINVOTE -BIGBLOCK
#BITCOINVOTE +BIGBLOCK
#BITCOINVOTE +MINERS
#BITCOINVOTE +DEVS
#BITCOINVOTE +HOLDERS

for example:

message = "#BITCOINVOTE +BIP8MB -BIP101 -BIP102 -BIP103 -BIPCBBSRA"
step1 - 1fb5a90f8f7eff851c32c498961a98f9d2b60417
step2 - 001fb5a90f8f7eff851c32c498961a98f9d2b60417
step3 - 6c2fddb0647247f2e2c97f17c87ebcf88fe82f4579e6cd9cc1f1077e4ba66d22
step4 - ec840e1f7122bfb89387675ebb1e9b1b6364a920bc44fbe982bd099a09deda69
step5 - ec840e1f
step6 - 001fb5a90f8f7eff851c32c498961a98f9d2b60417ec840e1f
step7 - 13tfZw4qS2SXeoLwxWPtQmcGD9st22g9VY

In this way the address for this message is 13tfZw4qS2SXeoLwxWPtQmcGD9st22g9VY

Address for message "#BITCOINVOTE -BIP101 -BIP103 -BIP8MB" is 1PeR4ZrioU6hNVofUyPijeJgWbmWbzdYLN

If you would like to vote for BIP101, but against BIP100 send 1 satoshi from all your addresses to 1LK5hwGUCZoYtU5tysU5EJr2dyWBUyM5hB

Vote against all block size increase proposals - 15u8F7EZPaVuRzQyUtMp1TSnvvJo8RGRJL

and so on

___
*Note that no one has the private keys for those addresses, therefore this satoshi will be lost forever

[funkenstein]

What about BIP000?   

http://www.cryptomashup.com/2015/09/bitcoin-i-support-bip000/

It appears to be the default, but if counting votes -- it should still be an option. 

[funkenstein]

Anonymous voting

Alternatively you can vote by sending 0.00000001 BTC to a special Bitcoin Address*. In that case the transaction must have no more than two outputs: one to address for voting, and one back to your initial address (known as change). Weight of the vote will be calculated proportional to this "change".

Bitcoin address for voting must be created in according to the following rules:
1 - Perform RIPEMD-160 hashing on the vote message
2 - Add version byte (0x00) in front of RIPEMD-160 hash
3 - Perform SHA-256 hash on the extended RIPEMD-160 result
4 - Perform SHA-256 hash on the result of the previous SHA-256 hash
5 - Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
6 - Add the 4 checksum bytes from stage 5 at the end of extended RIPEMD-160 hash from stage 2. This is the 25-byte binary Bitcoin Address
7 - Convert the result from a byte string into a base58 string using Base58Check encoding. This is the most commonly used Bitcoin Address format

vote message syntax:

Code:

#BITCOINVOTE {+|-}{BIP id} -{BIP id} -{BIP id} ...

where

- available BIP identifiers are: BIP100, BIP101, BIP102, BIP103, BIP8MB, BIPCBBSRA, BIPRosenfeld, BIPUpal
- only first BIP may begin with '+'
- BIPs starting with '-' must be listed in alphabetical order
- all BIPs must be separated by single spaces

for example:

message = "#BITCOINVOTE +BIP8MB -BIP101 -BIP102 -BIP103 -BIPCBBSRA"
step1 - 1fb5a90f8f7eff851c32c498961a98f9d2b60417
step2 - 001fb5a90f8f7eff851c32c498961a98f9d2b60417
step3 - 6c2fddb0647247f2e2c97f17c87ebcf88fe82f4579e6cd9cc1f1077e4ba66d22
step4 - ec840e1f7122bfb89387675ebb1e9b1b6364a920bc44fbe982bd099a09deda69
step5 - ec840e1f
step6 - 001fb5a90f8f7eff851c32c498961a98f9d2b60417ec840e1f
step7 - 13tfZw4qS2SXeoLwxWPtQmcGD9st22g9VY

In this way the address for this message is 13tfZw4qS2SXeoLwxWPtQmcGD9st22g9VY

Address for message "#BITCOINVOTE -BIP101 -BIP103 -BIP8MB" is 1PeR4ZrioU6hNVofUyPijeJgWbmWbzdYLN

If you would like to vote for BIP101, but against BIP100 send 1 satoshi from all your addresses to 1LK5hwGUCZoYtU5tysU5EJr2dyWBUyM5hB

and so on

___
*Note that no one has the private keys for those addresses, therefore this satoshi will be lost forever

For the record, I have no idea what you are trying to do here.

Sending one satoshi "from all your addresses" to a burn address ?  Note that I could make as many addresses for myself as I like. 

Why?  I thought you were trying to do a proof of stake vote?  One can simply sign with their private key; what you suggest requires getting the private key out of cold storage anyway to move the 1 sat.   

The mechanics of a coin-vote are self explanatory if you give them some thought, and we have created a platform so you can do exactly that.  Please take a look at our FAQ:

http://faq.coin-vote.com/

and read the white paper here:

http://frass.woodcoin.org/introducing-coin-vote/ 

Such a vote could be decentralized, but there seems little reason to do so.  All votes are public.  No money ever changes hands.  There's no way for the centralized counter (database administrator) to alter the tally --  every voter can verify his/her vote is on the list at any time and the tally is public.   

       

[funkenstein]

Oh, and here's a coin-vote on which proposal you like, or add others:

http://coin-vote.com/poll/55e8a33299baadff0a34acb7

Thanks to OP for suggesting the wording. 

[nLockTime]

What about BIP000?

There is an option "-BIGBLOCK" to vote against all block size increase proposals (has been added to my previous post)

Why?  I thought you were trying to do a proof of stake vote?

That's for paranoids. Just another way to prove that you are holder of an address' private key.
The advantage is that information is transferred through native bitcoin p2p protocol and votes are stored in the blockchain. But in that way anonymity is achieved at the cost of paying miner fees.

[nLockTime]

Note that I could make as many addresses for myself as I like

In that case most convinient way is to specify an email address and total number of your bitcoins.

[johoe]

Anonymous voting

Alternatively you can vote by sending 0.00000001 BTC to a special Bitcoin Address*. In that case the transaction must have no more than two outputs: one to address for voting, and one back to your initial address (known as change). Weight of the vote will be calculated proportional to this "change".

Don't do it this way; this just unnecessarily increases the UTXO size.  It is better to send 0 BTC to an OP_RETURN output.  Although this is not supported by most clients, it doesn't spam the UTXO set.  BTW, you cannot send 1 satoshi.  Most bitcoin nodes won't relay your transaction because it has a dust output, and even if it gets to the miners, it will probably not be accepted.  Another problem is that someone has to brute-force all hashes that correspond to a vote, because it is otherwise not possible to see if a hash is a vote and for which BIPs it votes.

Another question is, if the votes should be send to the blockchain at all, where they are stored forever.  Also you need some filtering logic to prevent people from voting twice with the same bitcoins.

[btcdrak]

BIPCBBSRA is now BIP105 at https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki

[nLockTime]

Another problem is that someone has to brute-force all hashes that correspond to a vote

It's not a problem. There are 1024+5 possible addresses.

Don't do it this way; this just unnecessarily increases the UTXO size. It is better to send 0 BTC to an OP_RETURN output. Although this is not supported by most clients, it doesn't spam the UTXO set

Good point. We must take into account all votes attached to the transactions with OP_RETURN. It would be nice to make a tool for creating such transactions.

BTW, I'm trying to provide an option to vote in a familiar way. It would be very useful to send coins in order to vote. And I guess the problem with spamming the UTXO can be solved otherwise. But first, we need to make a tool for voting with OP_RETURN and to come up with a solution for counting votes of holders with cold wallets.

Also you need some filtering logic to prevent people from voting twice with the same bitcoins

Logic is simple. 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.

BIPCBBSRA is now BIP105 at https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki

Updated

[coalitionfor8mb]

There are several proposals for optimizing Bitcoin's scalability:

BIP100 - Periodically change the limit based on block size vote by miners
BIP101 - Increase to 8 MB on January 11, 2016, and double the limit every two years
BIP102 - Increase to 2 MB on November 11, 2015
BIP103 - Block size according to technological growth
BIP105 - Consensus based block size retargeting algorithm
BIP106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP8MB - Increase to 8 MB
BIPRosenfeld - Elastic block cap with rollover penalties

...

Bitcoin is a mathematical money system and voting isn't the way mathematicians achieve consensus.

There must be a better way to do this, like figuring out the definition of Bitcoin first and then seeing what proposals fit the idea of Bitcoin moving forward better than others.

The fact that 8MB option stands out (in the OP) by not having a link to the BIP (truth doesn't need a BIP) hints us at the correct solution.

[nLockTime]

Bitcoin is a mathematical money system and voting isn't the way mathematicians achieve consensus.

There must be a better way to do this, like figuring out the definition of Bitcoin first and then seeing what proposals fit the idea of Bitcoin moving forward better than others.

Who are mathematicians? Why do you think they should decide which of proposals fit the idea?
Without a vote how do you know there is consensus achieved?