Each node does not need to seek out and download every fork, only ones that might matter.
Only shallow forks might become important, but they are also expensive to create. Deep forks are cheap, but will never win and can be ignored.
Topic: What stops short forks from taking up everyone's disk space? (Read 852 times)
There's checkpoints saved every so often, so you can't go past the latest checkpoint.
What stops those blocks from needing to be kept around indefinitely?
Nothing. Once you store a block on disk, it will stay there forever - that's the most common implementation.But you should note that mining blocks consts money, so people won't do this just to eat up your disk space - they prefer to mine a new block to earn 25BTC.
They can though try to create branches forking at low block numbers (where the difficulty is low), but most clients won't accept such an old blocks, so they won't store them in disk neither.
Why do you need to keep them? The only reason a fork could return is if someone thought it was the best chain and kept working on it. This means they would have all of this information, which should be retrievable. You need to catch up anyway if you disconnect from the network and return in an hour, this seems like it would be the same case. You keep track of what you think is the best chain, if someone gives you evidence of a better one, you replace what you know with what they give you.
I'm working on my own generic blockchain implementation, and I have a question about how Bitcoin ensures that everyone doesn't need to remember every fork that ever happened.
The longest chain always wins out, in the sense that that's the chain that the client looks at to see who has how many Bitcoins. But if I start getting blocks that fork off my current longest chain several blocks back, I need to keep those blocks around in case they end up forming a chain longer than the one I'm on. And there's no guarantee that I won't get half the blocks in this new longest chain today, and half tomorrow, so when I shut down my client, those blocks in the currently-shorter chain need to be saved to disk.
What stops those blocks from needing to be kept around indefinitely?
If the blocks do need to be kept around indefinitely in case their fork becomes the longest chain, what stops someone from solving a large number of blocks forking off some early, low-difficulty point in the chain, and taking up lots of disk space with all these forks?
The longest chain always wins out, in the sense that that's the chain that the client looks at to see who has how many Bitcoins. But if I start getting blocks that fork off my current longest chain several blocks back, I need to keep those blocks around in case they end up forming a chain longer than the one I'm on. And there's no guarantee that I won't get half the blocks in this new longest chain today, and half tomorrow, so when I shut down my client, those blocks in the currently-shorter chain need to be saved to disk.
What stops those blocks from needing to be kept around indefinitely?
If the blocks do need to be kept around indefinitely in case their fork becomes the longest chain, what stops someone from solving a large number of blocks forking off some early, low-difficulty point in the chain, and taking up lots of disk space with all these forks?
Jump to: