Is safely dropping old transaction history possible to save disk space?

[ssvb]

I'm new to bitcoin and its clones, so may be missing something. But the first impression is that the size of the block chain data is already huge and still growing, which is going to make the problem even worse. Moreover, I found some discussions about dust spam, which explodes the size of data and has to be stored forever with the current design. My current understanding is that the current data representation is the "genesis block" followed by the block chain which can be used to replay all the transactions from the very beginning.

But what about just generating some kind of complete "snapshots", which could contain just the balance of all the addresses? These snapshots could be created on a periodic basis, for example once a month or once a year. The block chain would look like this:
    "genesis block" - "block 1" - "block 2" - ... - "block N" - "snapshot" - "block N + 1" - "block N + 2" - ... - "block N + M" - ...

The interesting question is whether it could be possible to drop the original "genesis block" and eventually use "snapshot" as the new "genesis"? If all the blocks generated after "snapshot" also contain the hash of this "snapshot", then the "snapshot" would eventually accumulate enough "proof of work" confirmations, making it very difficult to replace with a fake (the bad guy would need to regenerate all the blocks after "snapshot" and supposedly just not have enough computational power for that). By the time when the next "snapshot" is scheduled to be created, the "genesis block" and the blocks 1 - N can be safely dropped (or archived) if needed.

Am I missing something?

[1713576014]

1713576014

[1713576014]

1713576014

[theymos]

Is safely dropping old transaction history possible to save disk space?

Yes, but the planned method is different than your method. Read the Bitcoin paper.

[ssvb]

OK, thanks for the pointer.

I did read the paper, but somehow forgot about it when browsing the dust spam discussion threads, which looked quite depressing. So the huge storage usage is at least not a design bug, but just an implementation issue?

[DeathAndTaxes]

OK, thanks for the pointer.

I did read the paper, but somehow forgot about it when browsing the dust spam discussion threads, which looked quite depressing. So the huge storage usage is at least not a design bug, but just an implementation issue?

It isn't a bug but even w/ block chain pruning a block chain will always require more resources than a ledger system.  Consider it a cost of not having a trusted third party.

Also I wouldn't say it is an implementation issue pruning simply hasn't been implemented.  It is also possible to construct lite clients which have no block chain stored and communicate w/ a trusted blockchain server.

[ssvb]

4.2MB of block headers per year is almost nothing when compared to the current more than 1GB of data in ".bitcoin" directory. Such small amount of data is not going to be a problem for any devices. And I don't quite like the idea of trusted blockchain server. It will encourage a lot of people to use such servers and make the system a lot less distributed and more vulnerable.

[DeathAndTaxes]

4.2MB of block headers per year is almost nothing when compared to the current more than 1GB of data in ".bitcoin" directory. Such small amount of data is not going to be a problem for any devices. And I don't quite like the idea of trusted blockchain server. It will encourage a lot of people to use such servers and make the system a lot less distributed and more vulnerable.

It is an inevitability if Bitcoin were to be adopted in any large scale fashion.  It doesn't mean you can't run your own private block-chain server.  Others may rely on public blockchain servers.  If you were paranoid you could design a client which contacts a large number of blockchain servers and looks for consensus before acting.