4 ms·

>>When you blow up the transaction limit you physically centralize the verification process. You could 500X the transaction throughput and running a full node

>>When you blow up the transaction limit you physically centralize the verification process. You could 500X the transaction throughput and running a full node would only require a 25 Mbps internet connection. >>Bigger blocks propagate more slowly, and magnify the advantage of employing those kinds of undesirable behaviors. Miners do not propagate blocks all at once. They use propagation protocols like compact blocks to only propagate the transactions not already in other nodes' mempools: https://ieeexplore.ieee.org/abstract/document/8922597 https://ieeexplore.ieee.org/abstract/document/8922597 The transactions fill the mempool over the course of the entire on average 10 minute duration between blocks, meaning that by the time a block is discovered, other nodes already have almost all of the transactions in that block. The 'validation free mining until the new block is fully propagated and validated' strategy further mitigates the competitive disadvantage miners face when receiving large blocks from other miners. All-in-all, centralization concerns do not justify preventing Bitcoin blocks from growing to meet market demand up until they reach at least 500 MB (ie. 3.3 MB/s of transaction throughput). The current 1 MB - or 1.6 MB assuming full SegWit adoption - limit, which only allows for 2 KB/s of transaction throughput, is absurdly inadequate, and makes Bitcoin's current energy consumption absurdly wasteful.

tal8d 6y ago
You are overlooking the disadvantage of not verifying the prior hash, which you can't do until you can verify hashMerkleRoot, which you can't do until you have collected the entire block. If you skip verification, you open yourself up to bad actors feeding you a bogus header - and you only figure that out after being drip fed a bunch of transactions that don't match the merkle root. Erasure coding doesn't fix that. In any case, proponents of the 'cram everything in the public ledger' method have already advocated 128MB and even completely uncapped block sizes... so the outcome is predictable. Take a hint from every successful network that has ever networked since ever: hierarchy, extensibility, etc. Demanding that it all be crammed into a homogenous block is so obviously doomed to fail that you should be suspicious of the proponents' motives.
- CyberDildonics 6y ago
  > being drip fed a bunch of transactions Where are you getting ideas like this? How fast do you think internet connections are? Only in the context of bitcoin do people start thinking 250 byte transactions are somehow difficult to send over gigabit connections. The average bitcoin block is 900 -kilobytes- at most at 10 minutes on average. How is it that people have absorbed propaganda that makes them actually think that causes anyone a problem? blizzard.com is 13MB, gfycat.com is 29MB. Who are these miners that are struggling to send out 900KB ?
  - tal8d 6y ago
    > Where are you getting ideas like this? How fast do you think internet connections are? As fast as the packet source wants? The only way to defend against a slowloris DoS is by accounting for it at the application layer, which is both unusual and difficult - as DoS attacks are usually handled at the transport layer. In this case that could mean applying a deadline for the block announcement in its entirety - which means mandating a minimum connection speed, and classifying every connection that dips below that as an attack... so you better have a good SLA with your upstream network. Well, that is no problem for centralized operations... Guess what happens to cryptocurrencies that adopt massive 128MB+ blocks in order to increase their transaction throughput - they become incredibly fragile as the slightest amount of packet loss starts waves of peer bans. > Who are these miners that are struggling to send out 900KB ? Anyone who wants to handicap a competing pool by forcing them to either wait for the complete false block, or waste time hashing on a fake block header. When are you going to admit that you haven't thought this through?
    - CyberDildonics 6y ago
      Now you are trying to say that for after 11 years, miners will for some reason sit and wait for someone that isn't sending them a block fast enough and that other miners will attack people like that. No one is waiting. If someone tries to send out a block slowly, someone else mines that block and sends it out fast. This is not difficult to understand. It's amazing all the made up nonsense you've thrown out to try to predict a future that has already come and gone. Why are you so desperate to prove something so ridiculous? What you are talking about doesn't happen at all at any throughput on any cryptocurrency.

tal8d 6y ago

You are overlooking the disadvantage of not verifying the prior hash, which you can't do until you can verify hashMerkleRoot, which you can't do until you have collected the entire block. If you skip verification, you open yourself up to bad actors feeding you a bogus header - and you only figure that out after being drip fed a bunch of transactions that don't match the merkle root. Erasure coding doesn't fix that. In any case, proponents of the 'cram everything in the public ledger' method have already advocated 128MB and even completely uncapped block sizes... so the outcome is predictable. Take a hint from every successful network that has ever networked since ever: hierarchy, extensibility, etc. Demanding that it all be crammed into a homogenous block is so obviously doomed to fail that you should be suspicious of the proponents' motives.

CyberDildonics 6y ago
> being drip fed a bunch of transactions Where are you getting ideas like this? How fast do you think internet connections are? Only in the context of bitcoin do people start thinking 250 byte transactions are somehow difficult to send over gigabit connections. The average bitcoin block is 900 -kilobytes- at most at 10 minutes on average. How is it that people have absorbed propaganda that makes them actually think that causes anyone a problem? blizzard.com is 13MB, gfycat.com is 29MB. Who are these miners that are struggling to send out 900KB ?
- tal8d 6y ago
  > Where are you getting ideas like this? How fast do you think internet connections are? As fast as the packet source wants? The only way to defend against a slowloris DoS is by accounting for it at the application layer, which is both unusual and difficult - as DoS attacks are usually handled at the transport layer. In this case that could mean applying a deadline for the block announcement in its entirety - which means mandating a minimum connection speed, and classifying every connection that dips below that as an attack... so you better have a good SLA with your upstream network. Well, that is no problem for centralized operations... Guess what happens to cryptocurrencies that adopt massive 128MB+ blocks in order to increase their transaction throughput - they become incredibly fragile as the slightest amount of packet loss starts waves of peer bans. > Who are these miners that are struggling to send out 900KB ? Anyone who wants to handicap a competing pool by forcing them to either wait for the complete false block, or waste time hashing on a fake block header. When are you going to admit that you haven't thought this through?
  - CyberDildonics 6y ago
    Now you are trying to say that for after 11 years, miners will for some reason sit and wait for someone that isn't sending them a block fast enough and that other miners will attack people like that. No one is waiting. If someone tries to send out a block slowly, someone else mines that block and sends it out fast. This is not difficult to understand. It's amazing all the made up nonsense you've thrown out to try to predict a future that has already come and gone. Why are you so desperate to prove something so ridiculous? What you are talking about doesn't happen at all at any throughput on any cryptocurrency.