4 ms·

> 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 representatio

> 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

maaku 11y ago
Not over the consensus parameters. You could have infinite hash power, but if your blocks are invalid they will be ignored.
- dontbelieveyou 11y ago
  https://github.com/bitcoin/bitcoin/blob/be9a9a3d2253ceccf123572b97a890c489a5a9be/src/main.cpp#L3175-L3185 https://github.com/bitcoin/bitcoin/blob/be9a9a3d2253ceccf123...
  - maaku 11y ago
    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.
    - dontbelieveyou 11y ago
      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?
      - maaku 11y ago
        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.
        dontbelieveyou 11y ago
        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/segregated-witness-and-its-impact-on-scalability/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/s...
- aback 11y ago
  "If" And if they are not?
digitsu 11y ago
This is exactly why I proposed this (rough) idea that nodes should have to ratify hard forks in some way. https://np.reddit.com/r/Bitcoin/comments/3y2ev1/what_if_nodes_were_able_to_be_selective_in_the/ https://np.reddit.com/r/Bitcoin/comments/3y2ev1/what_if_node...
kanzure 11y ago
> "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.
- dontbelieveyou 11y ago
  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.

maaku 11y ago

Not over the consensus parameters. You could have infinite hash power, but if your blocks are invalid they will be ignored.

dontbelieveyou 11y ago
https://github.com/bitcoin/bitcoin/blob/be9a9a3d2253ceccf123572b97a890c489a5a9be/src/main.cpp#L3175-L3185 https://github.com/bitcoin/bitcoin/blob/be9a9a3d2253ceccf123...
- maaku 11y ago
  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.
  - dontbelieveyou 11y ago
    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?
    - maaku 11y ago
      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.
      - dontbelieveyou 11y ago
        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/segregated-witness-and-its-impact-on-scalability/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/s...
aback 11y ago
"If" And if they are not?

digitsu 11y ago

This is exactly why I proposed this (rough) idea that nodes should have to ratify hard forks in some way. https://np.reddit.com/r/Bitcoin/comments/3y2ev1/what_if_nodes_were_able_to_be_selective_in_the/ https://np.reddit.com/r/Bitcoin/comments/3y2ev1/what_if_node...

kanzure 11y ago

> "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.

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