Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: nLockTime on August 26, 2015, 01:53:55 PM



Title: Voting for block size increase proposals
Post by: nLockTime on August 26, 2015, 01:53:55 PM
There are several proposals for optimizing Bitcoin's scalability:

BIP100 (https://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf) - Periodically change the limit based on block size vote by miners
BIP101 (https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki) - Increase to 8 MB on January 11, 2016, and double the limit every two years (will increase linearly based on the block's timestamp, and shall be 8GB after 20 years)
BIP102 (https://github.com/jgarzik/bips/blob/2015_2mb_blocksize/bip-0102.mediawiki) - Increase to 2 MB on November 11, 2015
BIP103 (https://gist.github.com/sipa/c65665fc360ca7a176a6) - Block size according to technological growth
BIP105 (https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki) - Consensus based block size retargeting algorithm
BIP106 (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki) - Dynamically Controlled Bitcoin Block Size Max Cap
BIP8MB - Increase to 8 MB
BIPRosenfeld (https://bitcointalk.org/index.php?topic=1078521) - Elastic block cap with rollover penalties

I suggest the following message syntax for voting anywhere in the internet for any BIP published on https://github.com/bitcoin/bips

The syntax is:
Code:
#BITCOINVOTE {vote version} {bitcoin address} {+|-|=}{BIP id} {+|-|=}{BIP id} ...
{signature}

For example:
Code:
#BITCOINVOTE 201508251200 12WRTDrnLy7FMHj8b4kNWPJgnDfseTK6cX =BIP100 +BIP101 -BIP102
H1TmFhlXT8vPnbWsLWDPs2qbWRWA1htZIuCd/Avts/OzaVsWfWcIzfOCqO9w/FmnQEkjve8UU4kZtEtoIN1CpEg=

where

201508251200 - (optional) vote version number or date (in format YYYYMMDDHHMM)
12WRT...K6cX - vote weight is proportional to balance of this address
=BIP100      - (optional) abstain from voting for BIP100
+BIP101      - (optional) vote for BIP101
-BIP102      - (optional) vote against BIP102
H1Tm...CpEg= - message signature

Special voting options:
{+|-|=}BIGBLOCK - to vote on all proposals relating to the increasing of block size
+MINERS - to withdraw in favour of miners decision
+DEVS - to withdraw in favour of developers decision
+HOLDERS - to support the decision of the majority of bitcoin holders

Automated service for voting
 
User friendly interface is available here: http://coinarchy.com (http://coinarchy.com)

Note that you can participate in the voting process even if you temporarily do not have access to the private keys of your bitcoins.
There is an option to enter addresses without signature and also number of your bitcoins on various services. Then enter your email address and you will be notified if your additional vote is needed for decision-making

Current results

BIP101 +2500.00 / -367.68
BIP105 +246.84 / -0.00
BIP102 +266.84 / -99.99
BIPRosenfeld +153.44 / -0.00
BIP100 +0.85 / -198.82
BIP8MB +0.00 / -198.82
BIP103 +0.00 / -342.48
BIP106 +0.00 / -2500.00

DEVS +0.036
BIP16 +0.000 / -20.000

You can find signatures here: http://coinarchy.com/results


Title: Re: BIP101 voting by bitcoin holders
Post by: RocketSingh on August 26, 2015, 01:59:01 PM
There are four proposals for optimizing Bitcoin's scalability:

No. There are more, e.g. https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki

A few others can be found here as well: http://bipsxdevs.azurewebsites.net/


Title: Re: BIP101 voting by bitcoin holders
Post by: achow101 on August 26, 2015, 02:11:20 PM
There are many more proposals than just those 4, although they don't have BIP numbers yet. There is also another thread that is already doing this here: https://bitcointalk.org/index.php?topic=1153957.0.

And why are you calling it BIP101 voting when this is clearly voting for more than just BIP 101?


Title: Re: BIP101 voting by bitcoin holders
Post by: nLockTime on August 26, 2015, 02:44:37 PM
And why are you calling it BIP101 voting when this is clearly voting for more than just BIP 101?
Only BIP101 is approved on https://github.com/bitcoin/bips. You can vote for other BIP with the condition that its ID will remain unchanged


Title: Re: Voting for a solution of scalability issue
Post by: nLockTime on August 31, 2015, 01:52:36 PM
User friendly interface is available on http://coinarchy.com (http://coinarchy.com)
Just answer the questions and submit the form


Title: Re: Voting for a solution of scalability issue
Post by: jonny1000 on August 31, 2015, 04:50:58 PM
BIP100 - Periodically change the limit based on observed block size, but never go larger than 32MB

BIP100 has nothing to do with "observed block size", miners vote for the limit using any criteria they like.  Rational miners should vote to maximize their own revenue.

Mining revenue = Block reward * exchange rate + average transaction fee * transaction volume * exchange rate


Title: Re: Voting for block size increase proposals
Post by: -ck on August 31, 2015, 09:14:21 PM
BIP100 - Periodically change the limit based on observed block size, but never go larger than 32MB
Incorrect - periodically change the limit based on block size vote by miners.


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on August 31, 2015, 09:31:52 PM
nLockTime, what if someone proposed a vote about how much of your money we all get to have? Would you vote in that poll? Sorry, but the only person who can control what gets into Bitcoin source are the people with commit access to the repo.

Yes, centralised. That's the model that works for software development. Where would this voting nonsense end? The alternative is to make development "equal opportunities", anyone and everyone gets a turn at designing and patching! Have fun with the coin you end up with using that development model  ::)


Title: Re: Voting for block size increase proposals
Post by: hexafraction on August 31, 2015, 10:20:07 PM
Yes, centralised. That's the model that works for software development. Where would this voting nonsense end? The alternative is to make development "equal opportunities", anyone and everyone gets a turn at designing and patching! Have fun with the coin you end up with using that development model  ::)


No, you're free to operate and mine on whatever client you want. If you're forked off the network, it's your fault.

Anyway, I don't see BIP103 in the list on the site linked.


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on August 31, 2015, 10:28:31 PM
Yes, centralised. That's the model that works for software development. Where would this voting nonsense end? The alternative is to make development "equal opportunities", anyone and everyone gets a turn at designing and patching! Have fun with the coin you end up with using that development model  ::)


No, you're free to operate and mine on whatever client you want. If you're forked off the network, it's your fault.

Not the user decision. That's not centralised. I didn't say that. I was talking about the development process. Not mining. It contributes to meaningful discussion if you read what you're replying to.


Title: Re: Voting for block size increase proposals
Post by: hexafraction on August 31, 2015, 10:34:29 PM
Yes, centralised. That's the model that works for software development. Where would this voting nonsense end? The alternative is to make development "equal opportunities", anyone and everyone gets a turn at designing and patching! Have fun with the coin you end up with using that development model  ::)


No, you're free to operate and mine on whatever client you want. If you're forked off the network, it's your fault.

Not the user decision. That's not centralised. I didn't say that. I was talking about the development process. Not mining. It contributes to meaningful discussion if you read what you're replying to.

I'm interpreting your statement in a slightly different manner than you may have intended. By modifying my own software, I am contributing to the overall development of the collection of software capable of processing, relaying, or mining transactions, assuming I'm also making it available. Additionally, by sharing it, I'm making it possible for anyone to pick up on those changes and use them on their own copy, or integrate them into a centrally-developed program.

On the other hand, nearly all the software that is USED is developed in a centralized fashion, but that doesn't apply to the overall process itself.


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on August 31, 2015, 10:51:36 PM
Yes, centralised. That's the model that works for software development. Where would this voting nonsense end? The alternative is to make development "equal opportunities", anyone and everyone gets a turn at designing and patching! Have fun with the coin you end up with using that development model  ::)


No, you're free to operate and mine on whatever client you want. If you're forked off the network, it's your fault.

Not the user decision. That's not centralised. I didn't say that. I was talking about the development process. Not mining. It contributes to meaningful discussion if you read what you're replying to.

I'm interpreting your statement in a slightly different manner than you may have intended. By modifying my own software, I am contributing to the overall development of the collection of software capable of processing, relaying, or mining transactions, assuming I'm also making it available. Additionally, by sharing it, I'm making it possible for anyone to pick up on those changes and use them on their own copy, or integrate them into a centrally-developed program.

On the other hand, nearly all the software that is USED is developed in a centralized fashion, but that doesn't apply to the overall process itself.

I see. Apologies for being terse, but your reply sounded like you were talking about a whole other topic. Call it BIP burn. :D

That's an interesting expansion on the way development works in practice, and I recognise what you're talking about from browsing around on Github. There are frequently forked projects with tiny differences, and it's totally plausible that the differences in these pet projects could end up ported to the main project (or that the tiny fork usurps the original). The more access there is to the code we use everyday, and the more we depend on that, I wonder whether this might become a trend.

There will always be a small set of people or an individual with sole commit access, necessarily so. But as you say, if someone forks that project and finds a significant enough userbase, the status of the previous dev team is being manifestly questioned. Overall, it's a good thing. I think we're all aware that it can be abused as well, particularly with consensus critical p2p networks.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 01, 2015, 01:51:28 PM
jonny1000, -ck, hexafraction,
Thank you. A brief descridption of BIP100 has been upated, BIPSIPA has been renamed to BIP103.

what if someone proposed a vote about how much of your money we all get to have? Would you vote in that poll?
People with commit access to the repo don't own the Bitcoin network.

Anyway the final decision will be made by bitcoin holders. If miners will support some nonsense BIP the people who disagree will cease using the system by "voting" for alternative stores of value. The purpose of suggested poll is to opportunely prevent this development.


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on September 01, 2015, 03:56:50 PM
what if someone proposed a vote about how much of your money we all get to have? Would you vote in that poll?
People with commit access to the repo don't own the Bitcoin network.

Anyway the final decision will be made by bitcoin holders. If miners will support some nonsense BIP the people who disagree will cease using the system by "voting" for alternative stores of value. The purpose of suggested poll is to opportunely prevent this development.

Allow me to understand: is it a blockchain fork you want to prevent? (not Core vs XT, but BIP vs BIP?) Your idea is that the miners will have accurate information about the will of the users, and choose that option unanimously?


Title: Re: Voting for block size increase proposals
Post by: amaclin on September 01, 2015, 04:13:22 PM
Bitcoin-qt doesn't provide any option for bitcoin holders to take part in voting for a solution of scalability issue.
Wrong. You can vote.
Just put the pattern into coinbase transaction, recompile code and execute "setgenerate true" in your debug console.
Your vote will be counted when you find block  ;D


Title: Re: Voting for block size increase proposals
Post by: newIndia on September 01, 2015, 04:36:24 PM
Bitcoin-qt doesn't provide any option for bitcoin holders to take part in voting for a solution of scalability issue.
Wrong. You can vote.
Just put the pattern into coinbase transaction, recompile code and execute "setgenerate true" in your debug console.
Your vote will be counted when you find block  ;D
The catch :P


Title: Re: Voting for block size increase proposals
Post by: amaclin on September 01, 2015, 04:41:47 PM
The catch :P
This is the bitcoin way for consensus. Anything else is just speculation.


Title: Re: Voting for block size increase proposals
Post by: newIndia on September 01, 2015, 04:56:03 PM
The catch :P
This is the bitcoin miner's way for consensus. Anything else is just speculation unknown so far.
FTFY... :)


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 01, 2015, 06:36:00 PM
Allow me to understand: is it a blockchain fork you want to prevent? (not Core vs XT, but BIP vs BIP?) Your idea is that the miners will have accurate information about the will of the users, and choose that option unanimously?
Yes, this would be the most profitable solution for all. On the whole I want to prevent the split of the community.

This is the bitcoin way for consensus. Anything else is just speculation.
Miners role is to prevent double spending, but not to decide whether pull requests should be accepted.


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on September 01, 2015, 08:13:37 PM
Allow me to understand: is it a blockchain fork you want to prevent? (not Core vs XT, but BIP vs BIP?) Your idea is that the miners will have accurate information about the will of the users, and choose that option unanimously?
Yes, this would be the most profitable solution for all. On the whole I want to prevent the split of the community.

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


Title: Re: Voting for block size increase proposals
Post by: teukon on September 02, 2015, 03:24:46 AM
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.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 02, 2015, 02:56:01 PM
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


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on September 02, 2015, 03:06:51 PM
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.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 02, 2015, 05:37:58 PM
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?


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on September 02, 2015, 05:40:29 PM
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.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 02, 2015, 05:47:20 PM
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?


Title: Re: Voting for block size increase proposals
Post by: Carlton Banks on September 02, 2015, 06:04:29 PM
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?


Title: Re: Voting for block size increase proposals
Post by: funkenstein on September 02, 2015, 06:34:25 PM
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

  


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 03, 2015, 01:07:33 PM
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.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 03, 2015, 06:03:25 PM
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 (https://en.bitcoin.it/wiki/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


Title: Re: Voting for block size increase proposals
Post by: funkenstein on September 03, 2015, 07:15:41 PM
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. 


Title: Re: Voting for block size increase proposals
Post by: funkenstein on September 03, 2015, 07:34:57 PM
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 (https://en.bitcoin.it/wiki/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.   

       


Title: Re: Voting for block size increase proposals
Post by: funkenstein on September 03, 2015, 07:47:38 PM
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. 


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 04, 2015, 01:34:25 PM
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.


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 04, 2015, 01:53:40 PM
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.


Title: Re: Voting for block size increase proposals
Post by: johoe on September 04, 2015, 03:05:31 PM
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 (https://en.bitcoin.it/wiki/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.


Title: Re: Voting for block size increase proposals
Post by: btcdrak on September 06, 2015, 10:53:48 PM
BIPCBBSRA is now BIP105 at https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 11, 2015, 08:14:07 AM
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


Title: Re: Voting for block size increase proposals
Post by: coalitionfor8mb on September 11, 2015, 02:59:47 PM
There are several proposals for optimizing Bitcoin's scalability:

BIP100 (https://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf) - Periodically change the limit based on block size vote by miners
BIP101 (https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki) - Increase to 8 MB on January 11, 2016, and double the limit every two years
BIP102 (https://github.com/jgarzik/bips/blob/2015_2mb_blocksize/bip-0102.mediawiki) - Increase to 2 MB on November 11, 2015
BIP103 (https://gist.github.com/sipa/c65665fc360ca7a176a6) - Block size according to technological growth
BIP105 (https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki) - Consensus based block size retargeting algorithm
BIP106 (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki) - Dynamically Controlled Bitcoin Block Size Max Cap
BIP8MB - Increase to 8 MB
BIPRosenfeld (https://bitcointalk.org/index.php?topic=1078521) - 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 (https://bitcointalk.org/index.php?topic=1174943.msg12382652#msg12382652) 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 (https://bitcointalk.org/index.php?topic=1162575.0)) by not having a link to the BIP (truth doesn't need a BIP) hints us at the correct solution (https://bitcointalk.org/index.php?topic=1174568.0). :)


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 11, 2015, 06:43:51 PM
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 (https://bitcointalk.org/index.php?topic=1174943.msg12382652#msg12382652) 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?


Title: Re: Voting for block size increase proposals
Post by: shorena on September 11, 2015, 06:58:06 PM
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


Title: Re: Voting for block size increase proposals
Post by: coalitionfor8mb on September 11, 2015, 07:42:10 PM
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 (https://bitcointalk.org/index.php?topic=1174943.msg12382652#msg12382652) 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?

Mathematicians are the ones who dig for the truth.
Once they reach that layer, they simply know they are there.
Theoretically you can achieve consensus all on your own.
But the challenge then becomes to let others see it as well.

I'm not saying that Bitcoin can't step out of its way as a result of popular vote.
It sure can, but the true path of the original Bitcoin isn't ambiguous.


Title: Re: Voting for block size increase proposals
Post by: teukon on September 11, 2015, 08:29:21 PM
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.


Title: Re: Voting for block size increase proposals
Post by: localhost on September 16, 2015, 01:22:07 PM
I suggest the following message syntax for voting anywhere in the internet for any BIP published on https://github.com/bitcoin/bips

The syntax is:
Code:
#BITCOINVOTE {vote version} {bitcoin address} {+|-|=}{BIP id} {+|-|=}{BIP id} ...
{signature}

For example:
Code:
#BITCOINVOTE 201508251200 12WRTDrnLy7FMHj8b4kNWPJgnDfseTK6cX =BIP100 +BIP101 -BIP102
H1TmFhlXT8vPnbWsLWDPs2qbWRWA1htZIuCd/Avts/OzaVsWfWcIzfOCqO9w/FmnQEkjve8UU4kZtEtoIN1CpEg=

[...]
Current results

BIP101  +2600.00 / -122.87
BIP100  +22.87 / -0.00
BIP102  +0.00 / -121.00
BIP103  +0.00 / -121.00
BIP106  +0.00 / -2600.00
Don't know if it's because I'm particularly clueless, but where should that signed message be posted? I see there are already some results so there must be a way, only it seems well hidden....


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 16, 2015, 02:19:02 PM
Don't know if it's because I'm particularly clueless, but where should that signed message be posted? I see there are already some results so there must be a way, only it seems well hidden....
I plan to add an option to dump the votes so anyone can verify them. But currently it's not a priority, because only a few people wished to vote. I think that to the end of the year there will be more people who want to take part in voting. Now I am working at creating the system of voting with cold wallets without getting the private keys.

Temporarily you can find signatures here: http://coinarchy.com/results


Title: Re: Voting for block size increase proposals
Post by: localhost on September 16, 2015, 05:46:48 PM
Thanks, I got it now. I got confused because your interface at coinarchy.com doesn't allow copy/pasting the signed text without clicking some buttons first.  ;D
I hope many people vote: even if the decision isn't necessarily decided straight from the poll, that would at least help to have an overview of what the community prefers.


Title: Re: Voting for block size increase proposals
Post by: adamstgBit on September 16, 2015, 06:16:53 PM
voted with 0.03BTC   :D

cool beans

Quote
Who should decide how the bitcoin protocol will be changed?
i voted devs, and then i have no option to choose what i think

altho i think devs should ultimately decide on protocol changes, i do think they should consider Holders opinions.

it would be nice if voting devs didn't lock me out of expressing my BIP preferences


Title: Re: Voting for block size increase proposals
Post by: nLockTime on September 16, 2015, 07:27:04 PM
i voted devs, and then i have no option to choose what i think

altho i think devs should ultimately decide on protocol changes, i do think they should consider Holders opinions.
Certainly devs will technically implement one or another solution. I think that decision will be legitimate if a majority of holders choose the same decision or delegate their votes to the developers.

it would be nice if voting devs didn't lock me out of expressing my BIP preferences
Ok, If nobody objects. I have disabled the lock.


Title: Re: Voting for block size increase proposals
Post by: funkenstein on September 20, 2015, 01:33:38 PM
https://i.imgur.com/H5v2OMz.png


Title: Re: Voting for block size increase proposals
Post by: Smokeasy on September 24, 2015, 06:38:22 PM
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/