7 ms·

Welcome to HN If you knew anything about Bitcoin Unlimited I am sure you would have come across its most fundamental aspect - moving the blocksize limited from

Welcome to HN If you knew anything about Bitcoin Unlimited I am sure you would have come across its most fundamental aspect - moving the blocksize limited from the hardcoded centralised protocol layer to the transport or messaging layer thus allowing each node operator to choose the limit in a decentralised fashion so creating an emergent consensus. In regards to your speculative economics, as I am sure you are aware, storage/bandwith/processing/validation and mining has costs. No one would therefore mine a transaction for free in 20 years because if they do so they would soon go bankrupt. Bitcoin's design has an inbuilt long term solution. Reward miners early on - grow adoption - increase transactions to a "very large number" - charge pennies out of millions of transactions - profit. Finally, LN may be secure for microtransactions. It is in no way secure for decent transactions. There are millions of ways it can be hacked even now that it only exists in speculative heads. Once it becomes hardcode implemented I am sure attack vectors will only increase much further.

maaku 11y ago
> If you knew anything about Bitcoin Unlimited I am sure you would have come across its most fundamental aspect - moving the blocksize limited from the hardcoded centralised protocol layer to the transport or messaging layer thus allowing each node operator to choose the limit in a decentralised fashion so creating an emergent consensus. If you knew anything about Bitcoin, you'd know that this is a sure-fire way to get forked off the network and ripped off by double-spends. The nature of Nakamoto consensus is such that consensus parameters are not up to vote.
- dontbelieveyou 11y 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
  - 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
  > 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]
- linhares 11y ago
  double-spend is now a feature, it's called rbf.

maaku 11y ago

> If you knew anything about Bitcoin Unlimited I am sure you would have come across its most fundamental aspect - moving the blocksize limited from the hardcoded centralised protocol layer to the transport or messaging layer thus allowing each node operator to choose the limit in a decentralised fashion so creating an emergent consensus. If you knew anything about Bitcoin, you'd know that this is a sure-fire way to get forked off the network and ripped off by double-spends. The nature of Nakamoto consensus is such that consensus parameters are not up to vote.

dontbelieveyou 11y 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
- 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
> 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]
linhares 11y ago
double-spend is now a feature, it's called rbf.