[tal8d]

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]

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

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

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]

Check the reference client buglist, they got hit with a slowloris resource exhaustion combo. They fixed the resource exhaustion (kind of), they did not address the slowloris vulnerability. So again, you have no idea what you're talking about. Doubly so if you didn't write the backend of a major mining pool - because you're just running your mouth about code you haven't seen otherwise.

[CyberDildonics]

Are you actually saying that a bug in bitcoin is a reason that no cryptocurrency can scale to many times more transaction throughput? Why do ethereum and bitcoin cash work so well?

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.

[CryptoPunk]

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

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.

[tal8d]

> Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW.

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"

The bad actor has full control of that, he just has to make sure the fake header has enough leading 0s in phony header nBits, the function that checks this is CheckProofOfWork() at https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L...

    Step 10) "Verify Merkle hash"

Well gee-wiz, how are we going to do that without having all the transaction in the block that the phony header hashMerkleRoot represents? GetHash() at https://github.com/bitcoin/bitcoin/blob/master/src/primitive...

[CryptoPunk]

That doesn't adrress my point at all. You can verify the requisite proof of work was done just by hashing the data in the block header to see if it meets the difficulty requirement.

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.

[CyberDildonics]

What kind of a response is this? They said anyone can verify the proof of work and you are saying they can verify the proof of work. Where is the contradiction?

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.

[tal8d]

> Where is the contradiction?

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.

[CyberDildonics]

No, he said that blocks are verified to have enough proof of work put into them. You were confused.