[dgenr8]

> 1. If consensus parameters cannot be voted on then Bitcoin is a failure, and Core's huge war against upstarts like XT and BU are totally misplaced (since as you say they cannot be changed by vote)

Eagerly awaiting a substantive response to this by maaku.

However I disagree with the BU proposition that unrestrained "voting" on max blocksize is a good idea. It doesn't stand up to attacks by a small amount of hash power.

[kanzure]

> > 1. If consensus parameters cannot be voted on then Bitcoin is a failure

> Eagerly awaiting a substantive response to this by maaku.

I am very much not maaku, but first it's obvious that Proof-of-Work has not been used to decide consensus protocol parameters (it's used for transaction ordering and establishing the consensus history). Second, Bitcoin success or failure is entirely unrelated to how the protocol wasn't designed to vote on consensus protocol parameters.

[aback]

Of course proof of work has always been used to decide consensus parameters. It's just tuat no controversial changes / failures to change have ever been put to the vote.

As long as the changes are non controversial then miners and nodes simply act at a rubber stamp. But it's unrealistic to think no important issues will be controversial.

If consensus changes arent up for CPU vote, then you tell me what happens if a supermajority of miners and nodes decide to run software with different consensus rule from Core? Sounds like a CPU vote too me.

[dontbelieveyou]

> it's obvious that Proof-of-Work has not been used to decide consensus protocol parameters

Every "soft-fork" to date has used PoW to activate new consensus rules by requiring block version super-majority.

[kanzure]

> Every "soft-fork" to date has used PoW to activate new consensus rules

Consensus rule parameters are things like "max block size". However, there have been some proposals for extension blocks to increase block size without requiring a hard-fork (e.g. using a soft-fork mechanism).