Hacker News Reader

Comment by TD-Linux | Hacker News Reader

The described system is basically identical to Bitcoin's pruned mode. It's lot better than geth's fast sync, which trusts your peers to not have messed with the state.

View on HN

I don't think there's any way they could mess with the state, since every block header has a merkle root of that block's state.

Highly unlikely, but in theory it should be vulnerable to birthday attack

If you can get hash collisions, then this issue is only one of many and that isn't exclusive to pruned modes. Bitcoin and friends rely pretty heavily throughout on the assumption of no hash collisions.

With 256-bit hashes, it would be many millions of years before a birthday attack succeeded.

That just prevents anyone except miners from messing with the state. One of the nice properties of Bitcoin is that even miners can't magic more coins into existence than allowed by the protocol or spend other people's money. You lose that a little with this kind of fast sync. It's probably worth it from a usability standpoint though.

Miners could mess with very recent state, but if you download enough blocks with full state to be confident of finality for the earliest one, and verify just those transitions, you're still safe.

If the incorrect blocks were published on the network, they'd be rejected by other miners, so you don't have to look far back unless (1) there's a sustained 51% attack on the whole network, or (2) you're a very juicy target and a huge miner can take over your internet connection, and you don't notice a large drop in difficulty.

Miners are already incentivized not to mess with the state.

Bitcoin prune node still downloads the full blockchain, just does not store all of it. It trusts the local file system, not other nodes.

Yeah that's what I meant, I updated my comment to be clearer.

But a pruned bitcoin node does not hold the full blockchain for other nodes to download. A pruned Ethereum node, however, does.

Reply on news.ycombinator.com