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.
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 ?
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?
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.
Did you write the backend of a mining pool and build in a bug where you wait for a block to be sent slowly? That's a pretty crazy mistake to just wait on a single connection.
Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW. If the malicious actor does produce sufficient PoW for their bogus header, they are foregoing massive block rewards to fool your node for a few seconds. That's why this kind of malicious activity doesn't happen, and why miners do validation free mining on a new header until they've verified the whole block.
Ok, I guess you don't know how verification works. Here are the 19 steps: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messag...
Step 4) "Block hash must satisfy claimed nBits proof of work"
Step 10) "Verify Merkle hash"
The malicious actor cannot fake that. They have to produce massive amounts of proof of work to find a value in the nonce data field in the block header that results in that hash meeting the required difficulty, and even if the malicious actor delays transmitting the whole block, they cannot delay transmitting the block header, or other nodes will not even bother trying to extend their block.
So all miners can immediately verify if the block headers they are receiving have the required PoW behind them, and it would be very costly for a malicious actor to generate fake block headers with enough PoW to be accepted, while giving the malicious actor very little advantage in an attack, meaning it would be a completely impractical and ineffective way to attack way to attack Bitcoin.
Verifying blocks is trivial. You aren't still saying that needing to receive 900KB is a big deal are you?
You seem to be acting like there is some sort of prediction that there will be a problem. Ethereum already produces blocks every 13 seconds at three times bitcoin's throughput.
I said that you can't verify the header until you have downloaded the entire block - meaning the time between a false header being submitted and the last transaction in the block being downloaded is time the miner either abandons its work on the last real block and then sits idle or risks hashing a new block prior to verifying the false header. He implied that you can somehow verify using the PoW. I demonstrate that you cannot. I'm not sure how you could have missed it.
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
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.