Hacker News new | ask | show | jobs
by dontbelieveyou 3835 days ago
> The nature of Nakamoto consensus is such that consensus parameters are not up to vote

"The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote." - Nakamoto

2 comments

> "Proof-of-work is essentially one-CPU-one-vote." - Nakamoto

Yes this is one of the things that Satoshi got wrong. "1 CPU = 1 vote" is wrong. Turns out that Proof-of-Work is unrelated to the physical quantity of CPUs, rather it's more about computation and hashrate. Also it's a stretch to call Proof-of-Work a vote ..... it's not an election, it's more like a random lottery or something.

He stated PoW was _essentially_ one-CPU-one-vote. It's clear that the intent is to mean hashrate, or CPU power as he phrases it multiple times in the same paper.

> it's not an election, it's more like a random lottery or something.

A random lottery where your odds of winning directly correlate with your CPU power / hashrate. The more you win the more influence you have over the state of the network. Comparing it to a vote is a reasonable analogy.

Not over the consensus parameters. You could have infinite hash power, but if your blocks are invalid they will be ignored.
Um, I'm not sure why you are pointing to that? ISM is used for soft-fork upgrades, which do not revert existing consensus rules. You can have a ISM vote over a new block size, but old clients will still reject the bigger blocks.
The upgrades are triggered by a super-majority of blocks of a certain version. This version maps to a possible new consensus rule. Block creation is a product of computational work. Therefore there is a precedent for CPUs/ASICs voting on the consensus rules of the system.

> ISM is used for soft-fork upgrades, which do not change existing consensus rules.

"Soft-forks" do change existing consensus rules. Will a miner's v1 blocks be accepted by the majority of the network today?

Which has no relevance to this conversation about BU and block size. Block size is not a parameter you can force on upgraded nodes by soft-fork.
You made the claim that under "Nakamoto consensus" the consensus parameters are not up for a vote. A correction seemed warranted.

> Block size is not a parameter you can force on upgraded nodes by soft-fork.

Isn't this what the Segregated Witness proposal[1] effectively does? The new limit proposed would be 4MB with an expected confirmed transaction throughput increase on the order of 2x.

To quote Pieter:

"Another way of looking at it, is that we raise the block size to 4 MB for the witness part, but the non-witness has same size."

[1] http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/s...

"If"

And if they are not?