3 ms·

> The nature of Nakamoto consensus is such that consensus parameters are not up to vote. One of two things must therefore be true: 1. If consensus parameters

by aback 11y ago

> The nature of Nakamoto consensus is such that consensus parameters are not up to vote. One of two things must therefore be true: 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) or 2. You're dead wrong If consensus parameters are not up to vote then obviously XT simply cannot be "voted in", so why fight it? If consensus parameters are not up for a vote then Bitcoin loses permissionlessness and censorship resistance: a hostile actor merely needs to infiltrate the governance structure of one ragtag dev team and he can block certain transactions or indeed greatly harm the network by inserting consensus code to keep undesirable txns out or by making the rules unworkable. Since nobody can vote the bad rules out, the network just has to accept the bad rules and implode. If consensus rules cannot be voted on then permissionless innovation of the system is thwarted or impossible. If I have a great idea for a consensus rule innovation, I have to get permission from the keepers of the consensus rules to add my rule change. If consensus rules are not up for vote then if a supermajority of users including miners attempt to change the rules by running different rules, nothing will happen, because the rules "weren't up to vote." But it is objectively the case that if this were to happen, then the rules would be changed because a majority of voters agreed with the change. This is the defacto behavior of Bitcoin. Methinks that #2 is the case. Consensus rules, as a simple matter of fact, are amenable to change by a simple supermajority of CPU votes from a majority of miners and nodes.

maaku 11y ago
You are free to read the code and see for yourself.
- aback 11y ago
  It is my reading of the code and understanding of the emergent crypto-economy that leads me to these self-evident conclusions. Are you refuting my points or agreeing with them? If you have an actual rebuttal to any of them, I'm interested in hearing it.
- deleted 11y ago
  [deleted]
dgenr8 11y ago
> 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 11y ago
  > > 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.
  - dontbelieveyou 11y ago
    > 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 11y ago
      > 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).
  - aback 11y ago
    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.

by aback 11y ago

maaku 11y ago

You are free to read the code and see for yourself.

aback 11y ago
It is my reading of the code and understanding of the emergent crypto-economy that leads me to these self-evident conclusions. Are you refuting my points or agreeing with them? If you have an actual rebuttal to any of them, I'm interested in hearing it.
deleted 11y ago
[deleted]

dgenr8 11y ago

> 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 11y ago
> > 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.
- dontbelieveyou 11y ago
  > 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 11y ago
    > 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).
- aback 11y ago
  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.