7 ms·

Do I have this right? Some miners want to increase blocksize, keeping Bitcoin in line with its original "peer to peer" nature, and thus are going to do Bitcoin

Do I have this right? Some miners want to increase blocksize, keeping Bitcoin in line with its original "peer to peer" nature, and thus are going to do Bitcoin Cash, with 8MB blocks to start. Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer. This kills the peer to peer aspect though, and end users would rely on offchain third parties to actually get transactions done. This group has fought to keep small blocks, despite recent congestion and increasing fees. The argument is that increasing blocksize can't solve all problems so why even start, and that increasing it even a bit would somehow prevent regular people from validating the chain. Complicating matters a bit is that some miners have an optimised way of mining, exploiting Bitcoin block header layout to get an optimisation during hash calculations (AsicBoost). This is a 20% advantage but also encourages mining occasional empty blocks. AsicBoost is incompatible with many suggestions of changing the Bitcoin protocol, giving economic incentives to object to such things. This muddies the water. On the other side, companies have invested a lot into becoming clearinghouses (Coinbase) or inventing ways to do offchain tx (Blockstream) casting doubt on their intentions of killing P2P and making BTC just for settlements. It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?

apeace 9y ago
Everything you said is correct AFAIK. > It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue? Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work. In fact, originally, everyone was in support of SegWit. Even the big-blocks camp (we can see that from the New York Agreement, where virtually the whole industry supported both big-blocks and SegWit). The only reason so many like Bitcoin Cash are against it today is because the debate has become emotionally-charged and us-versus-them. SegWit is an all-around good idea. But the Core developers held out from a blocksize increase because, once they had declared that going from 1MB -> 2MB would be the end of the world, the network would become "centralized", etc, they didn't want to walk it back and simply compromise. IMO, this is the main reason the ecosystem is migrating to Ethereum. It's not because of the Turing-complete scripting that is possible on Ehtereum, it's because development has been a lot more sane. Despite the problems they've had (e.g. the DAO), the Ethereum ecosystem is more diverse and professional. They rationally discuss problems and make tradeoffs. They encourage alternate implementations, whereas the Core folks have engaged in baseless fear tactics to ensure theirs is the only implementation on the network[0] (and not talking about protocol changes--simply alternate implementations of the same protocols and consensus rules). I think unless these leadership problems are addressed somehow, Bitcoin is going to fade into obscurity as others, like Ethereum, lead the way. [0] https://web.archive.org/web/20160316061949/https://blog.conformal.com/the-bitcoin-consensus-red-herring/ https://web.archive.org/web/20160316061949/https://blog.conf... --- EDIT: Corrected "Bitcoin ABC" to "Bitcoin Cash"
- Taek 9y ago
  > Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work. This statement demonstrates a very shallow understanding of the blocksize debate. There are a large number of reasons to object to any hardfork (causes instability and chaos, breaks compatibility, is a point of control for the people dictating the hardfork, is potentially opposed by many users, no easy way to measure support), and even more reasons to oppose a block size increase hardfork (doubling the blocksize worsens bottlenecks that are already significant, buys only a few months of time, is not a repeatable strategy to achieve real scalability, and the fight seems much more about control and pride than the actual block size - otherwise segwit would have been adopted immediately). As bitter as the fighting has been, the opposition to a block size increase hard fork stands on very solid ground.
- ChrisClark 9y ago
  I'd like to comment about something I realized when reading your post. About the difference between the Bitcoin development/community and the Ethereum one. If you want to completely oversimplify it, the Bitcoin community appears to be full of fear, anger, attacks and competition among themselves. While Ethereum seems to be compromise, inclusion, discussion, working towards a greater goal. You see a change proposed, and one developer comments that they think it's a bad idea for certain reasons. Then after a month of discussion he will come back and say that, yeah, I was wrong, it's actually a good idea. The recent multi-sig wallet hack was due to some bad refactoring by one of the developers on the Parity node/wallet team. Gavin Wood wrote a post about it, and instead of blaming his employee, he blamed himself, that he didn't put enough security into the Solidity language itself. And then he proposed some changes to make it safer. There definitely was some ugliness with the ETH/ETC fork and controversies, but now we have pull requests from ETC developers that help improve ETH. There seems to be a lot less ego in the Ethereum developer community. The fighting inside the Bitcoin community leads to attacking other communities too. Whenever there is a setback or hack or just the Ether price drops a bit, the threads are full of Bitcoiners coming in to laugh, attack, 'concern troll'. But you rarely see the reverse. Usually the attacks on Bitcoin come from the people who think all cryptocurrencies are a scam, they target everyone equally. Of course there are exceptions, there are amazing people in Bitcoin and horrible people in Ethereum. I'm just making a broad generalization on the feeling someone gets when reading and talking in their communities. It's no wonder that Ethereum has the largest developer interest, it's just a really nice place to work.
statoshi 9y ago
The argument is that higher cost of node operation is actually what kills the "peer to peer aspect." Trustless second layer networks such as Lightning use "third parties" to route money across the network, but never in a trusted/custodial fashion.
TD-Linux 9y ago
>It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue? Segwit, which activates on Bitcoin soon, already increases the the block size to ~2MB. Because Bitcoin Cash doesn't implement Segwit, increasing to merely the same size as Bitcoin wouldn't have been compelling.
- futuravenir 9y ago
  Increasing the block size is a fundamental change requiring a hard fork and a chain split. It is not possible to continue on the same chain with a 2mb block. However, they could continue on the same chain with segwit which gives the rough equivalent of a 1.7mb block. Unfortunately, that wasn't enough for the other side (+lots of other reasons, valid or not, I couldn't say).
  - apeace 9y ago
    Don't be fooled into thinking a soft-fork is the "same chain". It simply tricks nodes that don't know about SegWit into validating transactions that they don't really know how to validate. It's possible for a non-SegWit miner to accidentally mine an invalid block after the soft-fork. Here is how. The "backwards-compatibility" of SegWit comes from the fact that it looks like an anyone-can-spend transaction. Meaning, on the old blockchain, those coins would be up for grabs. Nodes that support SegWit know that it is not really an anyone-can-spend transaction, because they have extra data not included in the blockchain. But a node that doesn't upgrade doesn't know about this. So here's what could happen: 1) Bob sends sends a SegWit transaction to Alice 2) The non-SegWit node sees it as an anyone-can-spend transaction where Bob is basically giving up his coins 3) Eve wants to mess with the non-SegWit node, so she sends it a (valid!) transaction which spends Bob's coins and sends them to Eve 4) The non-SegWit miner mines a block with that transaction, and the block is consequently rejected by the SegWit nodes So SegWit needs 51% of hashing power in order to work, just like a hard fork. Without it, they wouldn't be able to reject the block with Eve's transaction, which would've been valid on the old blockchain. The only difference is that the above edge-case exists for a soft fork, whereas for a hard fork, non-upgraded nodes would simply be split into a smaller network instead of being tricked.
andrewla 9y ago
> Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer This is dramatically misconstruing the legitimate points made by the anti-big-blockers. The simplest fix would be to say "Others _are content with Bitcoin becoming a settlement layer_". Making changes is always dangerous given the fact that Bitcoin is fundamentally a consensus-driven protocol. So far, none of the block size proposals has managed to garner a significant consensus. Here I mean "consensus" in a general version of Satoshi's "one CPU one vote" consensus; that's the only consensus here that is resistant to Sibyl attacks. In addition there's the argument that increasing the block sizes necessarily entails increasing the orphaned block rate, which decreases network security. This happens because the larger the blocks are, the longer it takes for the network to recognize a legitimate block, and thus begin mining on top of it -- any mining that takes place after a block is found is wasted power and does not contribute to network security. There's also the notion of long-time viability of the decreasing block reward without developing and addressing the problems on forming a fee market to ensure that miner compensation is commensurate with their costs so that subverting the network will always be dramatically more expensive than helping the network. Finally there's the argument that block size increases make it more expensive to run full nodes by increasing space requirements. These are real concerns, not just some notion of "increasing blocksize can't solve all problems why even start". It happens that I disagree with this view; the first argument (forks are tricky) is, in my mind, the only valid one, and if Bitcoin Core threw their efforts behind finding a good, non-gameable, non-spammable block increase implementation, then we could get consensus.
narrator 9y ago
The lightning network works just fine as a daily transaction layer. Increasing the block size would never work as a large scale transaction system because the block size would have to grow to 100s of GB a day to reflect even a small percentage of total transactions. It's a short term hack that creates problems down the road.

apeace 9y ago

Everything you said is correct AFAIK. > It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue? Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work. In fact, originally, everyone was in support of SegWit. Even the big-blocks camp (we can see that from the New York Agreement, where virtually the whole industry supported both big-blocks and SegWit). The only reason so many like Bitcoin Cash are against it today is because the debate has become emotionally-charged and us-versus-them. SegWit is an all-around good idea. But the Core developers held out from a blocksize increase because, once they had declared that going from 1MB -> 2MB would be the end of the world, the network would become "centralized", etc, they didn't want to walk it back and simply compromise. IMO, this is the main reason the ecosystem is migrating to Ethereum. It's not because of the Turing-complete scripting that is possible on Ehtereum, it's because development has been a lot more sane. Despite the problems they've had (e.g. the DAO), the Ethereum ecosystem is more diverse and professional. They rationally discuss problems and make tradeoffs. They encourage alternate implementations, whereas the Core folks have engaged in baseless fear tactics to ensure theirs is the only implementation on the network[0] (and not talking about protocol changes--simply alternate implementations of the same protocols and consensus rules). I think unless these leadership problems are addressed somehow, Bitcoin is going to fade into obscurity as others, like Ethereum, lead the way. [0] https://web.archive.org/web/20160316061949/https://blog.conformal.com/the-bitcoin-consensus-red-herring/ https://web.archive.org/web/20160316061949/https://blog.conf... --- EDIT: Corrected "Bitcoin ABC" to "Bitcoin Cash"

Taek 9y ago
> Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work. This statement demonstrates a very shallow understanding of the blocksize debate. There are a large number of reasons to object to any hardfork (causes instability and chaos, breaks compatibility, is a point of control for the people dictating the hardfork, is potentially opposed by many users, no easy way to measure support), and even more reasons to oppose a block size increase hardfork (doubling the blocksize worsens bottlenecks that are already significant, buys only a few months of time, is not a repeatable strategy to achieve real scalability, and the fight seems much more about control and pride than the actual block size - otherwise segwit would have been adopted immediately). As bitter as the fighting has been, the opposition to a block size increase hard fork stands on very solid ground.
ChrisClark 9y ago
I'd like to comment about something I realized when reading your post. About the difference between the Bitcoin development/community and the Ethereum one. If you want to completely oversimplify it, the Bitcoin community appears to be full of fear, anger, attacks and competition among themselves. While Ethereum seems to be compromise, inclusion, discussion, working towards a greater goal. You see a change proposed, and one developer comments that they think it's a bad idea for certain reasons. Then after a month of discussion he will come back and say that, yeah, I was wrong, it's actually a good idea. The recent multi-sig wallet hack was due to some bad refactoring by one of the developers on the Parity node/wallet team. Gavin Wood wrote a post about it, and instead of blaming his employee, he blamed himself, that he didn't put enough security into the Solidity language itself. And then he proposed some changes to make it safer. There definitely was some ugliness with the ETH/ETC fork and controversies, but now we have pull requests from ETC developers that help improve ETH. There seems to be a lot less ego in the Ethereum developer community. The fighting inside the Bitcoin community leads to attacking other communities too. Whenever there is a setback or hack or just the Ether price drops a bit, the threads are full of Bitcoiners coming in to laugh, attack, 'concern troll'. But you rarely see the reverse. Usually the attacks on Bitcoin come from the people who think all cryptocurrencies are a scam, they target everyone equally. Of course there are exceptions, there are amazing people in Bitcoin and horrible people in Ethereum. I'm just making a broad generalization on the feeling someone gets when reading and talking in their communities. It's no wonder that Ethereum has the largest developer interest, it's just a really nice place to work.

statoshi 9y ago

The argument is that higher cost of node operation is actually what kills the "peer to peer aspect." Trustless second layer networks such as Lightning use "third parties" to route money across the network, but never in a trusted/custodial fashion.

TD-Linux 9y ago

>It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue? Segwit, which activates on Bitcoin soon, already increases the the block size to ~2MB. Because Bitcoin Cash doesn't implement Segwit, increasing to merely the same size as Bitcoin wouldn't have been compelling.

futuravenir 9y ago
Increasing the block size is a fundamental change requiring a hard fork and a chain split. It is not possible to continue on the same chain with a 2mb block. However, they could continue on the same chain with segwit which gives the rough equivalent of a 1.7mb block. Unfortunately, that wasn't enough for the other side (+lots of other reasons, valid or not, I couldn't say).
- apeace 9y ago
  Don't be fooled into thinking a soft-fork is the "same chain". It simply tricks nodes that don't know about SegWit into validating transactions that they don't really know how to validate. It's possible for a non-SegWit miner to accidentally mine an invalid block after the soft-fork. Here is how. The "backwards-compatibility" of SegWit comes from the fact that it looks like an anyone-can-spend transaction. Meaning, on the old blockchain, those coins would be up for grabs. Nodes that support SegWit know that it is not really an anyone-can-spend transaction, because they have extra data not included in the blockchain. But a node that doesn't upgrade doesn't know about this. So here's what could happen: 1) Bob sends sends a SegWit transaction to Alice 2) The non-SegWit node sees it as an anyone-can-spend transaction where Bob is basically giving up his coins 3) Eve wants to mess with the non-SegWit node, so she sends it a (valid!) transaction which spends Bob's coins and sends them to Eve 4) The non-SegWit miner mines a block with that transaction, and the block is consequently rejected by the SegWit nodes So SegWit needs 51% of hashing power in order to work, just like a hard fork. Without it, they wouldn't be able to reject the block with Eve's transaction, which would've been valid on the old blockchain. The only difference is that the above edge-case exists for a soft fork, whereas for a hard fork, non-upgraded nodes would simply be split into a smaller network instead of being tricked.

andrewla 9y ago

> Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer This is dramatically misconstruing the legitimate points made by the anti-big-blockers. The simplest fix would be to say "Others _are content with Bitcoin becoming a settlement layer_". Making changes is always dangerous given the fact that Bitcoin is fundamentally a consensus-driven protocol. So far, none of the block size proposals has managed to garner a significant consensus. Here I mean "consensus" in a general version of Satoshi's "one CPU one vote" consensus; that's the only consensus here that is resistant to Sibyl attacks. In addition there's the argument that increasing the block sizes necessarily entails increasing the orphaned block rate, which decreases network security. This happens because the larger the blocks are, the longer it takes for the network to recognize a legitimate block, and thus begin mining on top of it -- any mining that takes place after a block is found is wasted power and does not contribute to network security. There's also the notion of long-time viability of the decreasing block reward without developing and addressing the problems on forming a fee market to ensure that miner compensation is commensurate with their costs so that subverting the network will always be dramatically more expensive than helping the network. Finally there's the argument that block size increases make it more expensive to run full nodes by increasing space requirements. These are real concerns, not just some notion of "increasing blocksize can't solve all problems why even start". It happens that I disagree with this view; the first argument (forks are tricky) is, in my mind, the only valid one, and if Bitcoin Core threw their efforts behind finding a good, non-gameable, non-spammable block increase implementation, then we could get consensus.

narrator 9y ago

The lightning network works just fine as a daily transaction layer. Increasing the block size would never work as a large scale transaction system because the block size would have to grow to 100s of GB a day to reflect even a small percentage of total transactions. It's a short term hack that creates problems down the road.