Author

Topic: Checksums for blocks with pruned transactions (Read 512 times)

gst
newbie
Activity: 38
Merit: 0
The way how I understand the current approaches for pruning of transactions is that those approaches:

  • Allow a node that already stored the full blockchain to prune fully spent transactions
  • Still require the full unpruned blockchain to be initially transfered if the node should be able to validate transactions by itself

Are these assumptions correct?

If yes: Why can't each block also contain an additional checksum over the unpruned data in preceding blocks? So let's assume during runtime the client implementation dynamically generates a checksum over the unpruned data in every single block. Every new generated block contains an additional hash over all of those checksums in the preceding blocks, at the time when the block was generated. In addition, for every new transactions clients immediately prune old fully spent transactions and recalculate the checksum of the particular block. For every new block miners verify the hash over the checksums and only accept blocks if the hash corresponds with their locally calculated hash. This would allow a new validating client to only obtain the pruned blockchain and still be able to find out if its data is correct.

Are there any drawbacks of this approach that I overlooked? Or is this (or something similar) already implemented in clients (or planned for newer clients)?
Jump to: