Decentralized decision making, hashing toward a better bitcoin

[brg444]

"What's wrong with voting?

The OP is not proposing "voting" in the normal sense.  He is proposing that we simply make it very easy for node operators to download either BIP101, BIP100, 1-MB, etc.  If, for example, the majority of the hash power gets on board with larger blocks, then that's what Bitcoin will become.  He wants to give more power to the node operators (rather than to the developers of a particular implementation of the protocol (Core)).

Peter what you a proposing would more likely than not shatter bitcoin into a multitude a blockchain secured by fractions of hashing power. Your only hope is that somehow "free market" would eventually lead to a consensus, not before the network is broken to pieces by catastrophic consensus failure.

Here is what you actually propose to people is a "conservative choice":

The reason why BitcoinXT is dangerous and irresponsible is because it could potentially destroy Bitcoin and split the userbase into 2 separate Bitcoin networks. There are very good reasons why most of the core developers and Bitcoin experts are super cautious with increasing the block size too quickly. But these reasons are hard to explain to regular users of Bitcoin. Yet, it is quite easy for Mike & Gavin to convince people that supporting BitcoinXT means supporting block size increase, which makes Bitcoin scale for worldwide use, and it's what Satoshi intended. BitcoinXT is set to trigger with 75% miner support. This means it can trigger with only 50% miner support + a lucky streak. Or if there are malicious people running NoXT, they can cause the trigger to go off without majority support. When that happens, there's no guarantee that the losing side will all switch to running BitcoinXT. Now you've got a split user base and miner base. Some wallets will support BTC, some will support BTCXT, and some may support both. Same for exchanges and payment processors. It's going to be total chaos. Miners will switch back and forth between mining BTC and BTCXT. Users will send transactions on one network and not know why the recipient didn't get it. The price for both coins will tank. If you thought Litecoin and altcoins dilute the value of Bitcoin, wait til you see what BTCXT does to the price! Actually, the market is already giving us a hint as to why BitcoinXT is such a bad idea.

from https://www.reddit.com/r/Bitcoin/comments/3hp190/charlie_lee_nuclear_option_of_forking_the/cu9e4tj

Get a grip won't you. Don't use your research to support a network attack. You've made your block size intentions clears but that doesn't mean you have to rally behind a governance coup just because they pretend to share your same ideals.

And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments.

This attempt could seriously damage developer trust and discourage some much needed mind share from maintaining our infrastructure. Mike has repeatedly stated he prefers a very authoritarian method of development. In the event that core essentially becomes XT he has explicitly stated decisions would come down to him.

Think this through properly and figure out if this is preferable to an historically reliable group of core dev applying proven, consensus-based, improvement implementations.

[Peter R]

...
And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments...

I support increasing the block size limit.  Right now, showing support for XT seems to be the most efficient means of achieving that goal.

Longer term, I would like to see several implementations of the Bitcoin protocol controlled by different groups of developers.  In other words, I'd like the square on the right here to have several smaller squares inside it (and no square [including Core] > 30%), thereby decentralizing development:



What in your opinion would be wrong with that longer-term goal of decentralizing development?

[johnyj]

By making it easier for nodes to "express their acceptance of a block" (e.g., for blocks larger than 1 MB), we are making it easier for the network to come to consensus according to the original design of Bitcoin.  
 

If a consensus is reached, you don't need to vote. If you need to vote, you don't have consensus. Or to say, only a 100% passed vote can be called consensus

That's way vote always works much faster than consensus building, while consensus based decision will satisfy almost everyone. The key is to satisfy EVERYONE

I sounds like we're arguing semantics.  My definition of "consensus" with regards to Bitcoin is empirical: the longest chain composed of valid transactions has "consensus."  It sounds like you view consensus as more like unanimity.  I'm not saying either of us is right or wrong in our definitions.  However, my definition seems more practical: we can measure the longest chain.  How can we tell if 100% of the network supports something?  Under what conditions is it reasonable to expect exactly 100% support for something?

Furthermore, isn't it clear that 100% of the network is not in favour of keeping the block size limited at 1 MB?  Why should stasis be the default in the case of a stalemate?

I don't exactly understand how longest chain can be a measure? when you have a fork, both chain is the longest in its own version of bitcoin

My understanding is that consensus building should involve everyone in bitcoin ecosystem. There are many large actors who don't even run bitcoin nodes, not even mention hash power, they also have their own interest and concern

[Peter R]

I don't exactly understand how longest chain can be a measure? when you have a fork, both chain is the longest in its own version of bitcoin

One chain will have a greater cumulative work in it--this work is objectively measurable. This is what is meant by the longest chain (assuming both chains are composed of valid transactions, of course).  

According to the Bitcoin white paper (Section 5):

 "Nodes always consider the longest chain to be the correct one and will keep working on extending it."

My understanding is that consensus building should involve everyone in bitcoin ecosystem. There are many large actors who don't even run bitcoin nodes, not even mention hash power, they also have their own interest and concern

I completely agree!

[johnyj]

If a consensus is reached, you don't need to vote. If you need to vote, you don't have consensus. Or to say, only a 100% passed vote can be called consensus

That's way vote always works much faster than consensus building, while consensus based decision will satisfy almost everyone. The key is to satisfy EVERYONE

Step 5 of your model is to "Test The Proposal" in which there is a kind of "voting" that is going on. I think the consensus mechanism being discussed is the best way to implement step 5 of your consensus model. Ultimately a "voting" period is necessary, but the end result is 100% consensus with the best proposal.

Exactly, that article still involves some vote to test if everyone is satisfied with the decision. But it is a very abstract directive, how we should implement it in bitcoin community is to be seen

Anyway, in a consensus based decision making, we can at least say that we have made all the possible efforts to reach a 100% consensus, so no one feel that he is left over

For example we have solution A,B,C,D,E, after several rounds of evaluation we realized that solution D have the most support and the least resistance, so we could select D as the solution. In this way, the people originally against D will understand that D is the best consensus we can reach, so if he take consensus as the highest priority, he would accept D, although D is not his favorite. Of course D should not be strongly resisted by any one, that will not make it a suitable solution

[BitProdigy]

Exactly, that article still involves some vote to test if everyone is satisfied with the decision. But it is a very abstract directive, how we should implement it in bitcoin community is to be seen

We implement the "vote to test if everyone is satisfied with the decision" on the block chain as just "votes". Not actually forking. Isn't there a way to do like they are doing with XT and notate which proposal you support without actually forking the chain. This voting process would be a true "test" not an actual race to the final solution. After the "test period" we can all as a community decide if we should pull the trigger on a certain date to begin implementing the fork that gained the consensus.

Anyway, in a consensus based decision making, we can at least say that we have made all the possible efforts to reach a 100% consensus, so no one feel that he is left over

For example we have solution A,B,C,D,E, after several rounds of evaluation we realized that solution D have the most support and the least resistance, so we could select D as the solution. In this way, the people originally against D will understand that D is the best consensus we can reach, so if he take consensus as the highest priority, he would accept D, although D is not his favorite. Of course D should not be strongly resisted by any one, that will not make it a suitable solution

You are absolutely correct and that is why I am so glad you brought this up, this is indeed exactly what bitcoin needed

[phelix]

once a version number achieves 90% of hashing power that would be considered the communities will miners will

FTFY

hash power != community will

[johnyj]

once a version number achieves 90% of hashing power that would be considered the communities will miners will

FTFY

hash power != community will

Exactly, there are many people who do not run nodes or mining but still greatly concerned about bitcoin's health since they use it daily.

I think at least the participants should have some level of involvement. It is difficult for someone who does not own any bitcoin to make any decision because he simply don't understand the whole thing

Use node to vote can be misleading, since you can create thousands of SPV nodes on virtual server. Hash power is more reliable but that excludes most of the participants (I guess winkelvoss twins do not own any hash power), and as 2013 fork showed, it can be manipulated by large pool owner

[Muhammed Zakir]

...
And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments...

I support increasing the block size limit.  Right now, showing support for XT seems to be the most efficient means of achieving that goal.

Longer term, I would like to see several implementations of the Bitcoin protocol controlled by different groups of developers.  In other words, I'd like the square on the right here to have several smaller squares inside it (and no square [including Core] > 30%), thereby decentralizing development:

[ img width=800]https://i.imgur.com/VzqyqwR.gif[/img]

What in your opinion would be wrong with that longer-term goal of decentralizing development?

Many clients, each (hard)forking blockchain. How great would it be?!

[zimmah]

To be honest it sounds like a "popularity contest" rather than a well thought out technical solution to a problem (this has been my thinking about this whole issue ever since XT embarked on the alarmist idea that Bitcoin is going to die and that they are going to fork by "convincing others" that they should follow them).

you don't think the most popular solution would tend to be the one which appears to be well thought out technical solution to the problem??

Sadly, no. Because the majority of humans is not always right, in fact, it's often quite the opposite.

[adamstgBit]

To be honest it sounds like a "popularity contest" rather than a well thought out technical solution to a problem (this has been my thinking about this whole issue ever since XT embarked on the alarmist idea that Bitcoin is going to die and that they are going to fork by "convincing others" that they should follow them).

you don't think the most popular solution would tend to be the one which appears to be well thought out technical solution to the problem??

Sadly, no. Because the majority of humans is not always right, in fact, it's often quite the opposite.

the idea is that the devs offer viable BIPs with more or less the same amount of "correctness" but they are in disagreement as to which one to pick, and so they politly poll the nework to see where the hashing power / enocomc marjorty stand. in hopes that this allows them to make the best decision for everyone invloded

[adamstgBit]

after chatting and thinking about it, I have edited OP, hopefully this addresses some concerns you all have.

[adamstgBit]

"What's wrong with voting?

The OP is not proposing "voting" in the normal sense.  He is proposing that we simply make it very easy for node operators to download either BIP101, BIP100, 1-MB, etc.  If, for example, the majority of the hash power gets on board with larger blocks, then that's what Bitcoin will become.  Give more power to the node operators (rather than to the developers of a particular implementation of the protocol (Core)).

That's still a vote, what if the minority of the hash power don't want to use larger blocks? You are still forcing a change on them. And those minorities might command much larger stake in bitcoin ecosystem than you can imagine, they could easily destroy your majority fork with the flip of a pen

Please read this article again if you are interested
http://www.seedsforchange.org.uk/consensus

In this "voting system" there is no winner, it is simply informative, it actually jives with your Consensus Decision Making, the goal with be to get the network agreeing at 90%, first we might see 50/50 on 1MB vs 20MB then the devs make changes to there BIP say 8MB and get more of the network agreeing.

[adamstgBit]

I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalk.org/index.php?topic=1160026.0

there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.

here are a few thoughts about the details that might make this process more streamlined:

by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.

all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"

when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.

when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )

to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to  undecided. included the possibility of knocking off  "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.

[Peter R]

That is not a question... No miners will make any significant switch unless they get equally significant node support

Switching to XT is the conservative decision, as illustrated in the figure below.

That is if anyone actually plans to move to XT, which they don't.

Seriously wake up Peter, no one is buying it.

14% of the nodes are buying it as of today.  That's up from 0% a little over a week ago.  Let's see how much of the hash power is buying it two months from now...

This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies.  Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.  




Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf

[knight22]

That is not a question... No miners will make any significant switch unless they get equally significant node support

Switching to XT is the conservative decision, as illustrated in the figure below.

[img]http://-snip-[img]

That is if anyone actually plans to move to XT, which they don't.

Seriously wake up Peter, no one is buying it.

14% of the nodes are buying it as of today.  That's up from 0% a little over a week ago.  Let's see how much of the hash power is buying it two months from now...

[img]http://-snip-[img]

This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies.  Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.  

[img]http://-snip-[img]


Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf

Core devs "There is no need for bigger blocks!"  

Bunch of idiots in their ivory tower...

[brg444]

That is not a question... No miners will make any significant switch unless they get equally significant node support

Switching to XT is the conservative decision, as illustrated in the figure below.

That is if anyone actually plans to move to XT, which they don't.

Seriously wake up Peter, no one is buying it.

14% of the nodes are buying it as of today.  That's up from 0% a little over a week ago.  Let's see how much of the hash power is buying it two months from now...

This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies.  Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.  

...

Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf

All part of the little coordinated XT push. A good cop/bad cop trap for suckers to fall in. Unscrupulous lobbying of VC-backed companies willing to throw a bone to the investors for more funding rounds.

"Look Mr. Banker, we just upgraded the Bitcoin network to support 8X more transactions, that should get us some users! You all know Bitcoin users LOVE to make transactions right, right?"

Until today, our involvement has consisted of listening, researching and testing.

Where is the research? Can we see the "tests"?

Can't these industry "leaders" wait until the actual industry has met for a final push to a resolution (Scaling Bitcoin) until picking sides?

Speaking of "ivory tower" what use should we, the community, make of this pathetic PR coup? Are we supposed to just swallow this and take it for granted these guys have done their research? Of course we shouldn't shame them with our suspicion or any reconsideration or validation of their actual motivations and reasoning.

These are the bankers of the Bitcoin world and you are sucking up them without any discretion because...they're VCs & entrepreneurs so they must know what they're doing and surely what they are doing is for the best of everyone in Bitcoin, right. Right?

[brg444]

I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalk.org/index.php?topic=1160026.0

there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.

here are a few thoughts about the details that might make this process more streamlined:

by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.

all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"

when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.

when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )

to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to  undecided. included the possibility of knocking off  "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.

Adam.

If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".

[adamstgBit]

I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalk.org/index.php?topic=1160026.0

there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.

here are a few thoughts about the details that might make this process more streamlined:

by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.

all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"

when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.

when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )

to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to  undecided. included the possibility of knocking off  "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.

Adam.

If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".

hashing power And amount of BTC ??

when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart

easy as pie.

its happening one way or the other.... why fight it?

[brg444]

I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalk.org/index.php?topic=1160026.0

there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.

here are a few thoughts about the details that might make this process more streamlined:

by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.

all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"

when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.

when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )

to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to  undecided. included the possibility of knocking off  "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.

Adam.

If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".

hashing power And amount of BTC ??

when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart

easy as pie.

its happening one way or the other.... why fight it?

As gool ol Romanian chap Mircea would say : read the logs.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/