Why would it be a bad idea to snapshot the blockchain and prune it for everyone?

[20kevin20]

So right now if you wanted to run a full node, you'd have to sync the entire blockchain from its inception, back when addresses were all empty. This uses a lot of storage and makes syncing take way too long for an average PC.

But I was just wondering: as long as the blocks are accepted by the majority of nodes/miners, what is the need of having so many hundreds of thousands of blocks stored? If nodes accept and successfully verify the last.. say 100 blocks, then why is it necessary to also store the other n-100 (where n = number of mined blocks since Bitcoin's inception)?

I understand that syncing from zero and preserving the entire blockchain makes it pretty impossible for history to be manipulated. But wouldn't it make more sense to basically snapshot all the current balances of addresses and start over from there, storing only the last 100 blocks and, every time the 101st block is mined, to store the 1st mined block as a now-permanent, verified change of the addresses' balance and then the wallet would remove it from the device, now basically considering the newly mined block (the 101st) as being the 100th and so on?

[1715180275]

1715180275

[1715180275]

1715180275

[1715180275]

1715180275

[BlackHatCoiner]

You're right in some parts. Prune node seems a known phrase to me. Isn't there an option like this already existing? Anyway, without being sure for what I state, snapshotting the blockchain and prune it for everyone wouldn't be possible for a simple reason. Harmony. Who is going to force all the nodes not to keep the entire blockchain on their storage? The network started with some consensus rules. They can't just change.

But I believe that you're right. This is something that would solve lots of problems. It reminds me another change I had suggested in the past which was locking the blocks after X confirmations. This would prevent any 51% attacks.

[pooya87]

Bitcoin relies on certain principles, one of them is that you verify everything instead of trusting others. The only thing we all agree on are the hard-coded genesis block and the consensus rules. If we take a snapshot and discard the history then any new member will have to trust those who have been around and were involved in the process and they can not trust us to not have created coins out of thin air for ourselves!

Besides who is going to create the snapshot and hardcode it into the protocol? Miners? Devs? some company? Any of these will centralize bitcoin.

When you prune your blockchain, you are still downloading and verifying everything from the start so you don't trust anyone. But also you do it only once. It may be tedious act but from that point until you delete your node you will only have to download and verify new blocks not the history anymore. And at the same time you save space on your disk.

[ranochigo]

I think you answered your own question. It isn't necessary for nodes to store the blocks once they are verified.

You have to preserve the history and that is done through the full non-pruned nodes like we have now. Synchronization is relied on those nodes to supply the full blockchain history.

I think the main issue of your question is the time and the bandwidth needed to synchronize the blockchain? I think having full nodes to not synchronize from the genesis block is out of the question; they will have to trust someone to provide the accurate and correct information which is not what Bitcoin is designed to do. Starting from n-100 block requires the node to obtain the accurate information about the state of Bitcoin before that and that is fairly difficult to do.

Bitcoin works by the concept of UTXOs and the synchronization process builds the chainstate as it validates all the block. The current pruning gives a suitable cushioning in case of a long block reorg.


I don't think having snapshots is the answer to the question of reducing the Blockchain. At least all the attempts I see so far compromises the ability of the client being independent and trustless.

[20kevin20]

I previously thought pruned mode actually syncs the blockchain and only stores all the blocks containing txs from your wallet, making it require a complete resync in case of importing private keys or a new "wallet.dat" file - hence why I never tried it out. So basically, pruned node is exactly what I was thinking of? As in, removing the history to preserve disk space while still counting and verifying all the future blocks and still being able to work for the most part like a full node?

Now about trust, isn't it basically still having to trust someone the fact that we download blocks from peers?

[ranochigo]

I previously thought pruned mode actually syncs the blockchain and only stores all the blocks containing txs from your wallet, making it require a complete resync in case of importing private keys or a new "wallet.dat" file - hence why I never tried it out.

It only stores the block as defined in your size for the pruning. It does however, store all the transactions related to the wallet (and it's addresses) that you've synchronized with. Since it discards all the blocks prior to your pruning limit, it cannot retrieve any information about imported addresses/wallets.

So basically, pruned node is exactly what I was thinking of? As in, removing the history to preserve disk space while still counting and verifying all the future blocks and still being able to work for the most part like a full node?

Yes. The only disadvantage is the one you mentioned and that it is less useful as it is able to serve lesser blocks to it's peers.

[mocacinno]

--snip--
Now about trust, isn't it basically still having to trust someone the fact that we download blocks from peers?

You download these blocks from multiple peers, AND all consensus rules still apply... This means that a sybil attack would be extremely costly, since the fake blocks should still follow all rules, so an attacker would basically have to mine an alternative VALID blockchain AND make sure your node only connects to his attack nodes.

As for this topic, the main point has already been made: trust...

If you want to be your own bank, and verify everything, you need to download and parse all blocks. If you don't want to verify everything: use an SPV client...

[BrewMaster]

Now about trust, isn't it basically still having to trust someone the fact that we download blocks from peers?

you don't trust, you follow the longest chain to reach consensus with everyone else.
you start by connecting to a peer and tell them you only have 1 block (genesis block). they will send you 2000 headers and you continue receiving headers until they stop giving you more.
now you connect to another peer and tell them you have these block headers (send about 20 of your last heights with increasing distance). if you are missing anything or have invalid chain they will send you the valid one.
so far you have only downloaded and verified about 40 MB of data but you know what the longest chain is. but now you can start downloading the blocks of those headers but now you can do it from multiple nodes.

each time you connect to a new node you both check your chains against each other to make sure you have the same thing.

eventually you end up checking with everyone that you connect to to make sure you all are in agreement on which chain is the longest.

[ABCbits]

I previously thought pruned mode actually syncs the blockchain and only stores all the blocks containing txs from your wallet, making it require a complete resync in case of importing private keys or a new "wallet.dat" file - hence why I never tried it out.

You also need to complete resync download if you intentionally close the wallet and it's long enough where unscanned block already pruned.

I previously thought pruned mode actually syncs the blockchain and only stores all the blocks containing txs from your wallet, making it require a complete resync in case of importing private keys or a new "wallet.dat" file - hence why I never tried it out.

It only stores the block as defined in your size for the pruning. It does however, store all the transactions related to the wallet (and it's addresses) that you've synchronized with. Since it discards all the blocks prior to your pruning limit, it cannot retrieve any information about imported addresses/wallets.

Pruned mode also stores UTXO (also called chainstate), which required to verify whether the input is valid or not.

[20kevin20]

Alright, thanks for the replies. Will close this topic now as I think I got enough answers to understand the answer to my question from multiple points of view. Thanks! Well, learning in the crypto space is a never-ending process..