The mining process makes it expensive to lie to the network, but if no one is checking for lies it could still be lied to. Full nodes check that mining nodes aren't including invalid transactions. The requirement to submit a valid hash with your mined block means that the network can't be spammed into oblivion. Check the hash first (cheap), and if the hash passes, check /everything/ in the block to make sure it's all valid (expensive). If the block contains only valid transactions accept it, federate it to your peers, and thus give the miner lots of money. If the block contains any invalid transactions, reject it, thereby levying on the miner an opportunity cost for doing the wrong thing.
Removing the second step of validation would mean that you could attack the network with considerably less than 51% hash power. You could buy 1% of the hashpower and submit fraudulent blocks 1% of the time on average. Note that submitting fraudulent blocks is not the same kind of attack as a 51% attack.
Anyway, you see this "full nodes don't validate the blockchain" nonsense a lot from altcoins that think they've found a neat-o way to get faster/cheaper transactions. They usually have, but they invariably have to lose the trustless nature of the system to do it, at which point you'd be better of using a regulated bank. It's a big red flag that the developer of a coin doesn't actually understand the technology they are using.
> Anyway, you see this "full nodes don't validate the blockchain" nonsense a lot from altcoins that think they've found a neat-o way to get faster/cheaper transactions.
I am not saying "full nodes don't validate the blockchain". I am explaining that full nodes (on both Bitcoin as well as Bitcoin Cash) don't validate historical blocks. This would take way too much time, and as I explain in the article doesn't really reduce trust in the software.
Here is the mechanism by which the Bitcoin Core implementation uses "assumevalid":
Checkpoint blocks are an interesting topic, but there's a mile between checkpoint blocks and "full nodes don't validate transactions so why bother keeping that block data around?".
They're also not about trust, they're about protecting against DoS attacks:
Even with checkpoint blocks, a full node can elect to validate it's entire history if it chooses to, which again is a far cry from "block history data is worthless because full nodes don't validate it", a flagrantly untrue statement.
Another fantastic proposal by one of the Bitcoin Cash devs. It seems BTC is experiencing a serious brain drain as a result of the block size war.
Sadly this innovation won't work near as well on the BTC chain unless usage continues to plummet. As we've seen in the past, the slightest short term increase in transaction demand results in fees so high that most outputs in the utxo set become unrecoverable (the fee becomes greater than the value of the output). This leaves the BTC utxo set unmanageable and unpredictable.
Although the utxo set on BCH grows at a much greater rate, the 32mb block size makes it so that outputs can be inexpensively consolidated, regardless of short term transaction demand.
That being said, Lightning Network could potentially allow this innovation on BTC if it's able to successfully move transactions off chain. With the trouble they've been having with regards to routing and payment channel requirements, I wouldn't be HODLing my breath.
> This leaves the BTC utxo set unmanageable and unpredictable.
Although this is true, I don't think this eliminates the possibility of such UTXO commitment. It is iteratively updated every block and doesn't care about predictability.
The code as written could be easily merged into BTC as well.
The only small difference would be in backtracking: When we have full node that uses fast syncing we could implement that they retrieve older blocks until they are satisfied (either by assumevalid or some accumulated work), and verify from that point. They can simply apply the commitment backwards.
On Bitcoin Cash, this would require block propagation that includes the TxOuts being spent by the block.
This is a bit more difficult on Bitcoin to the difference in sighashing: these TxOuts aren't directly committed transactions that spend them.
12 comments
[ 2.5 ms ] story [ 49.5 ms ] threadThis is straight up not correct:
https://bitcoin.org/en/developer-guide#p2p-network
https://en.bitcoin.it/wiki/Full_node#Economic_strength
https://en.bitcoin.it/wiki/Myths#Miners.2C_developers_or_som...
The mining process makes it expensive to lie to the network, but if no one is checking for lies it could still be lied to. Full nodes check that mining nodes aren't including invalid transactions. The requirement to submit a valid hash with your mined block means that the network can't be spammed into oblivion. Check the hash first (cheap), and if the hash passes, check /everything/ in the block to make sure it's all valid (expensive). If the block contains only valid transactions accept it, federate it to your peers, and thus give the miner lots of money. If the block contains any invalid transactions, reject it, thereby levying on the miner an opportunity cost for doing the wrong thing.
Removing the second step of validation would mean that you could attack the network with considerably less than 51% hash power. You could buy 1% of the hashpower and submit fraudulent blocks 1% of the time on average. Note that submitting fraudulent blocks is not the same kind of attack as a 51% attack.
Anyway, you see this "full nodes don't validate the blockchain" nonsense a lot from altcoins that think they've found a neat-o way to get faster/cheaper transactions. They usually have, but they invariably have to lose the trustless nature of the system to do it, at which point you'd be better of using a regulated bank. It's a big red flag that the developer of a coin doesn't actually understand the technology they are using.
Citation: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial...
https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a...
Full nodes validate a lot of blocks at initial sync, but not all of them.
https://news.ycombinator.com/item?id=17233986
Please check the code.
Please check the discussion:
https://www.reddit.com/r/Bitcoin/comments/5yf0ex/trust_assum...
Please check the news:
https://bitcoinmagazine.com/articles/bitcoin-core-0140-relea...
Or just run your own node: bitcoind --help and see what it says.
https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a...
> Anyway, you see this "full nodes don't validate the blockchain" nonsense a lot from altcoins that think they've found a neat-o way to get faster/cheaper transactions.
I am not saying "full nodes don't validate the blockchain". I am explaining that full nodes (on both Bitcoin as well as Bitcoin Cash) don't validate historical blocks. This would take way too much time, and as I explain in the article doesn't really reduce trust in the software.
Here is the mechanism by which the Bitcoin Core implementation uses "assumevalid":
https://github.com/bitcoin/bitcoin/blob/7f4db9a7c3549a36e45d...
They're also not about trust, they're about protecting against DoS attacks:
https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial...
Even with checkpoint blocks, a full node can elect to validate it's entire history if it chooses to, which again is a far cry from "block history data is worthless because full nodes don't validate it", a flagrantly untrue statement.
> "block history data is worthless because full nodes don't validate it"
Please don't misquote people.
Sadly this innovation won't work near as well on the BTC chain unless usage continues to plummet. As we've seen in the past, the slightest short term increase in transaction demand results in fees so high that most outputs in the utxo set become unrecoverable (the fee becomes greater than the value of the output). This leaves the BTC utxo set unmanageable and unpredictable.
Although the utxo set on BCH grows at a much greater rate, the 32mb block size makes it so that outputs can be inexpensively consolidated, regardless of short term transaction demand.
That being said, Lightning Network could potentially allow this innovation on BTC if it's able to successfully move transactions off chain. With the trouble they've been having with regards to routing and payment channel requirements, I wouldn't be HODLing my breath.
Although this is true, I don't think this eliminates the possibility of such UTXO commitment. It is iteratively updated every block and doesn't care about predictability.
The code as written could be easily merged into BTC as well.
The only small difference would be in backtracking: When we have full node that uses fast syncing we could implement that they retrieve older blocks until they are satisfied (either by assumevalid or some accumulated work), and verify from that point. They can simply apply the commitment backwards.
On Bitcoin Cash, this would require block propagation that includes the TxOuts being spent by the block.
This is a bit more difficult on Bitcoin to the difference in sighashing: these TxOuts aren't directly committed transactions that spend them.