Hacker News new | ask | show | jobs
by CryptoPunk 1926 days ago
>>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.

1 comments

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

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.

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

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