Why don't we prune to scale?

[j4k0b]

So, I got into an argument with a friend and we were discussing on scaling problems of the blockchain.
As the blockchain gets bigger and bigger, why don't we just save the state of the blockchain (by which I mean all the utxos) every year and hash the preceding blocks, so we know that this is the correct state and erase these blocks afterwards?

[1714925909]

1714925909

[1714925909]

1714925909

[1714925909]

1714925909

[bitmover]

So, I got into an argument with a friend and we were discussing on scaling problems of the blockchain.
As the blockchain gets bigger and bigger, why don't we just save the state of the blockchain (by which I mean all the utxos) every year and hash the preceding blocks, so we know that this is the correct state and erase these blocks afterwards?

As far as I know, prune has nothing to do with scaling. It will only reduce the Blockchain size, which doesn't affect scalability, but only full node maintenance. (Please correct me if I'm wrong)

Scalability is related to blocktime and blocksize mostly.
Faster blocktime, faster confirmations. More blocksize, more transactions in the same block, so faster confirmations

[j4k0b]

First of all, thanks for answering.
I am gonna expand my argument: The whole discussion about increasing the blocksize was about the resulting size of the chain and the resulting bandwith a bigger blockchain would cause, wasn't it? So, if we pruned and agreed on a valid state of the blockchain, wouldn't we be able to reduce the size of the chain and therefore reduce the caused bandwith? I see why just increasing the blocksize wouldn't be able to ultimately scale the bitcoin network but wouldn't we be able to get some on chain scaling going?
In other words: Why do we need full nodes when we could have an agreed on past and lite nodes?

[darosior]

First of all, thanks for answering.
I am gonna expand my argument: The whole discussion about increasing the blocksize was about the resulting size of the chain and the resulting bandwith a bigger blockchain would cause, wasn't it? So, if we pruned and agreed on a valid state of the blockchain, wouldn't we be able to reduce the size of the chain and therefore reduce the caused bandwith? I see why just increasing the blocksize wouldn't be able to ultimately scale the bitcoin network but wouldn't we be able to get some on chain scaling going?
In other words: Why do we need full nodes when we could have an agreed on past and lite nodes?

Hi,

If every Bitcoin node was a pruned one, if a new node wanted to sync the chain it musts trust others (some state), whereas today it computes every transaction and PoW since the Genesis block : no need to trust anyone.

EDIT : You could answer to that that the Genesis block is hardcoded into the code so we could hardcode just another one. These hardcoded blocks exist and are called checkpoints, deleting the Genesis block and relying only on checkpoints would cause a high centralization coming from the devs.

EDIT2 : While searching for some links to provide I just noticed I'm wrong since December 2018 (link to the tweet from Peter Todd) :

Core removed checkpoints and replaced it with known-good block hashes, a move that I'm at least partially responsible for. I'm in support of that obviously, but it's important that people realize the potential dangers if the community fails to audit them properly.

[bitmover]

I am gonna expand my argument: The whole discussion about increasing the blocksize was about the resulting size of the chain and the resulting bandwith a bigger blockchain would cause, wasn't it? So, if we pruned and agreed on a valid state of the blockchain, wouldn't we be able to reduce the size of the chain and therefore reduce the caused bandwith?

No. Even if all past blocks were reduced to 1mb instead of 200Gb, the bandwidth would still be a problem for nodes if blocksize is big, because they would need to have a high bandwidth to keep themselves updated.

For now you need about 500mb/day (15gb month) according to https://bitcoin.org/en/bitcoin-core/features/requirements to run a full node.

I see why just increasing the blocksize wouldn't be able to ultimately scale the bitcoin network but wouldn't we be able to get some on chain scaling going?

Certainly, but there are other more elegant solutions that doesn't increase bandwidth requirements. Such as segwit, that simply reduce transaction size, which has the same effect of increasing blocksize without increasing bandwidth requirements.

In other words: Why do we need full nodes when we could have an agreed on past and lite nodes?

Full nodes are necessary for decentralization purposes. If everyone relies on light nodes, bitcoin would be centralized. Let´s suppose someone propose a solution that you need 50gb/day to run a node. Few people would be able to run a full node, and those few nodes could be a point of failure and would probably be attacked. The security of the network relies in it decentralization.

There are many actors in bitcoin network: miners, full nodes, light nodes, users sending and receiving, developers (third party developers also), etc...

All of them are necessary to keep the network decentralized and running.

[khaled0111]

In other words: Why do we need full nodes when we could have an agreed on past and lite nodes?

We need full nodes because it is the only way to check the validity of new transactions by passing through all previous blocks. /pruned nodes would replace full nodes if your balance was really updated and linked to your address after each transaction.

Keeping full nodes running is also needed to detect and prevent double spending which is not possible to do with pruned nodes.

Now, what if a hard fork is needed and the blockchain should be forked at an old block that pruned nodes don't have a record for it!

[achow101]

What you are describing is an idea that has been floating around for several years now. You're not the only one to think of it.

The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?

Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.

To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.

There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.

[KingZee]

---

I tried to be the devil's advocate and side with OP, but I just couldn't find a way to remove the trust factor from the utxo set.

To reformulate it in simpler words for OP, because you have the full bockchain, you can effectively verify every transaction from day 1, starting from the genesis block. You don't need to trust anyone to figure out where every single bitcoin ended up through years of transactions.

Once you chop off a few blocks, you can no longer do that. Let's say in the 2nd block satoshi sent money to your address, who's going to prove it? There's definitely going to be chaos because you no longer can re-create the full utxo set, and people will try to abuse this in a heartbeat.

I genuinely cannot come up with any kind of workaround because verifying every single transaction from day 1, beats by miles having to trust another source. Even if a lot of wallets only use the utxo now, at any moment it can be verified, bitcoin is truly beautiful.

[aliashraf]

-snip-
it introduces some centralizing trust.
-snip-
there is going to be more trust ...

So, we got another Centralization Threat Alert, CTA.
Congratulations, we are a great community with so many centralization tracking procedures that all are convincing us how great bitcoin is and why we shouldn't touch anything about it "recklessly".

You are wrong, deeply wrong bro, and it is killing me because I love you and other guys who have devoted your lifes to bitcoin and this community, I sincerely appreciate it but you are so wrong. Bitcoin is the most important innovation in this century if not the whole modern history, but there is no reason to keep it "as is" or to suppose there is no way to make it better.

Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.

I understand you are trying to educate a newbie meanwhile and it is great to remind challenges but your conclusion is unreasonably biased. There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.

To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.

Miners couldn't collude for inserting malicious UTXO commitment to blocks, for the same reason that they couldn't do it for any other form of malicious data: full nodes will reject such blocks and commit to the alternative healthy chain.

Speaking of centralization, let's take a look at trade-offs involved:

• Current Situation
  • pros:
    • secure against complete chain rewrite attacks
    • nothing else
  • cons:
    • centralization threats due to the lack of an incentive system for running full nodes while they are getting more and more costly and hard to setup
    • downward compatibility and software bloat because of the need for re-running the protocol from root
    • inherent resistance to change and evolution in time
• UTXO Commitment
  • pros:
    • secure against very long chain rewrite attacks hence practically safe against this class of attacks
    • Great decentralization effects because of realization of fast and cheap fully functional nodes
    • Improved software quality because of significant reduction in need for downward compatibility.
  • cons:
    • vulnerability to ultra-long/complete chain rewrite attacks which are not practical anyway
    • nothing else

[DooMAD]

Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.

I understand you are trying to educate a newbie meanwhile and it is great to remind challenges but your conclusion is unreasonably biased. There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.

If the change results in a contentious fork, which it almost certainly would, participants on the newly-formed network will believe whatever the newly-forked nodes tell them.  There would be ample opportunity for collusion during the execution of a fork.  People have had lots of practice spotting fairly obvious things like premines and changes to the capitalisation that some forks have previously attempted to sneak in, but they may not notice something as subtle as a UTXO change. 

[achow101]

There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.

That is completely wrong. First of all, nodes do not just have a hard coded hash of the genesis block. The genesis block is small, so it is hard coded into the software itself. Furthermore, because the genesis block is small, one can visually inspect the hard coded value and see that it is correct. Furthermore, it is extremely obvious if you have the wrong genesis block: none of the blocks that you have will show up on any node you connect to or on any block explorer!

But a UTXO set as initial state, that's very different. Hardcoding a UTXO set is unfeasible because it is large. Because it is large, you can't visually inspect it and make sure that there are no unexpected UTXOs there. If it is wrong and does omit or have an extra UTXO, you can't tell that you have the wrong UTXO set until a UTXO you don't have or an extra UTXO you have is spent causing a hard fork. Sure hard coding a hash would help, but you are still trusting that the UTXO set that matches that hash is correct.

These are two different things, to say that they are the same is disingenuous.

Miners couldn't collude for inserting malicious UTXO commitment to blocks, for the same reason that they couldn't do it for any other form of malicious data: full nodes will reject such blocks and commit to the alternative healthy chain.

New nodes coming online won't know. Under this scheme, a new node that comes online is unable to verify that their initial UTXO set is correct. They can be forked off onto a separate chain which has an invalid initial UTXO set and the new node would have no idea.

Speaking of centralization, let's take a look at trade-offs involved:

Current Situation
pros:

• secure against complete chain rewrite attacks
• nothing else

You forget a few.

• Almost no trust in any third parties required. The only trust necessary is in developers for software whose code can also be independently audited
• The entire history from the beginning of Bitcoin is verifiable

• downward compatibility and software bloat because of the need for re-running the protocol from root

Have you looked at Bitcoin Core in regards to the consensus rules? There's very little bloat because the protocol really hasn't changed that much. Those things that would cause bloat have been reduced to simple if statements or outright removed (BIP 34 style activation has been entirely removed and those soft forks are activated by block height/block hash or enforced from genesis).

• inherent resistance to change and evolution in time

Why is that a con? The blockchain is supposed to be immutable after all. Not only that, but BItcoin does evolve, just slowly and cautiously, as you should be when dealing with a system that handles large amount of money.

• Great decentralization effects because of realization of fast and cheap fully functional nodes

There's more to decentralization than just more nodes. More nodes does not mean more decentralization. Take Ethereum for example. It has many light nodes, but I would not say it is decentralized. They are centralized under the Ethereum developers who can just say "we're having a hard fork at this time" and then say "sorry guys, hard fork canceled" and the entire network just does as they say. That is not decentralization, but they have many nodes.

• Improved software quality because of significant reduction in need for downward compatibility.

Just about everything that is currently needed for consensus validation would be needed in the UTXO commitment model. In fact, this would cause more bloat because now we have to handle a new rule: UTXO commitments. All of the other things needed for backwards compatibility like non-segwit outputs still need to be maintained.

cons:

• vulnerability to ultra-long/complete chain rewrite attacks which are not practical anyway
• nothing else

You forgot a few:

• Increased trust in third parties

And if you are talking about UTXO commitments in every block, there's more cons:

• Additional time to validate and produce blocks due to the need to hash the UTXO set
• Issues with commitments themselves where they do not necessarily commit to all UTXOs or collide and commit to UTXOs that do not exist

Now I'm not saying the UTXO commitments are universally bad. It is an active area of research and someone may come up with a breakthrough which allows us to do this kind of pruning trustlessly. However, as it is now, UTXO commitments introduce more trust in others, and pruning the blockchain so that it is just an initial UTXO set from which blocks are built on is simply introducing too much trust to the system.

But UTXO commitments will certainly be useful even if they introduce more trust. Instead of pruning the blockchain to some initial state, they would allow for a faster sync. You can do a sort of Hybrid sync where you use a UTXO set initially and check it against UTXO commitment in blocks so that you can be synced very quickly. Then in the background the blockchain can be downloaded and checked. This would allow the best of both worlds: you can have a faster sync and reduce your node's resource usage, and the full history is still verifiable and you can verify that the UTXO set you received initially is correct. This would be optional: for those who want to have a faster sync and don't care that they are trusting others, they can use the UTXO commitments. For those who want a faster sync and are okay with initially trusting but later verifying the UTXO set, they can use the hybrid sync. And for those who want to have the least amount of trust in others and to verify everything, they can do the full sync of the blockchain.

[aliashraf]

Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.

I understand you are trying to educate a newbie meanwhile and it is great to remind challenges but your conclusion is unreasonably biased. There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.

If the change results in a contentious fork, which it almost certainly would, participants on the newly-formed network will believe whatever the newly-forked nodes tell them.  There would be ample opportunity for collusion during the execution of a fork.  People have had lots of practice spotting fairly obvious things like premines and changes to the capitalisation that some forks have previously attempted to sneak in, but they may not notice something as subtle as a UTXO change. 

I've proposed  Soft Delayed UTXO Commitment   which I don't want to get into it right now but take a look into it if you would, to find out there are definite possibility to deal with any possible challenge involved as utxo commitment could be delayed and processed decently to have a super soft migration:

[aliashraf]

There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.

That is completely wrong. First of all, nodes do not just have a hard coded hash of the genesis block. The genesis block is small, so it is hard coded into the software itself.

It is irrelevant, no need to any hardcopy of the raw genesis block, just a small, I mean very small optimization it is, not important in protocol level.

Furthermore, because the genesis block is small, one can visually inspect the hard coded value and see that it is correct.

Again not a critical point and not a cryptographic best practice: No need to this feature at all and there is always a pay off for such hacks. As far as the protocol (not speaking about the implementation) is considered Genesis hash is enough for securing the boot process.

But a UTXO set as initial state, that's very different. Hardcoding a UTXO set is unfeasible because it is large. Because it is large, you can't visually inspect it and make sure that there are no unexpected UTXOs there.

No need to hard coding neither the genesis raw block nor a hypothetical UTXO.  For the latter we don't need even the hash. PLease check the link to SDUC above.
According to my proposed algorithm, nodes do not check any initial-utxo, they just need an arbitrary number of blocks as their pruning length and can tune how many commitments they need to be achieved bu a utxo to be considered secure. A straightforward calculation would show that a SDUC compatible node with like 10,000 pruned blockchain is secure against attacks that cost up to half a billion USD with current prices and hashrates. Far more than enough for most of the ordinary applications.

Miners couldn't collude for inserting malicious UTXO commitment to blocks, for the same reason that they couldn't do it for any other form of malicious data: full nodes will reject such blocks and commit to the alternative healthy chain.

New nodes coming online won't know. Under this scheme, a new node that comes online is unable to verify that their initial UTXO set is correct. They can be forked off onto a separate chain which has an invalid initial UTXO set and the new node would have no idea.

Not necessarily, even current spv nodes do not commit to an invalid chain. It is absolutely possible for nodes to download block headers before starting to count number of commitments made by latest blocks to a candidate UTXO, note that in this scheme I've propose a reverse verification algorithm in which we verify the blockchain from latest blocks down.

Speaking of centralization, let's take a look at trade-offs involved:

Current Situation
pros:

• secure against complete chain rewrite attacks
• nothing else

You forget a few.

• Almost no trust in any third parties required. The only trust necessary is in developers for software whose code can also be independently audited
• The entire history from the beginning of Bitcoin is verifiable

ok, but the first one is obvious and common between the two methods and the second one is not an advantage, just a disaster pointed as a limitation.

• downward compatibility and software bloat because of the need for re-running the protocol from root

Have you looked at Bitcoin Core in regards to the consensus rules? There's very little bloat because the protocol really hasn't changed that much. Those things that would cause bloat have been reduced to simple if statements or outright removed (BIP 34 style activation has been entirely removed and those soft forks are activated by block height/block hash or enforced from genesis).

The activation of forks based on block height/hash is an example of software bloat and your argument is not correct anyway because we are not speaking of just last ten years, think more strategic.

• inherent resistance to change and evolution in time

Why is that a con? The blockchain is supposed to be immutable after all. Not only that, but BItcoin does evolve, just slowly and cautiously, as you should be when dealing with a system that handles large amount of money.
[/quote]
Securing money needs evolution and adoption when you impose backward compatibility on nodes it acts like an artificial inertia that complicates things and increases the risks, it is why bitcoin has evolved slowly. To be honest it hasn't happened intentionally and because you guys have been cautious it has always been about downward compatibility. I understand there is a natural inertia as well and there should be, but it is just about the need for guaranteeing few things 1-inflation policy 2-security, 3-immutability (of data, not the protocol nor the code) 4-decentralization and 5-censorship resistance.  

• Great decentralization effects because of realization of fast and cheap fully functional nodes

There's more to decentralization than just more nodes. More nodes does not mean more decentralization. Take Ethereum for example. It has many light nodes, but I would not say it is decentralized. They are centralized under the Ethereum developers who can just say "we're having a hard fork at this time" and then say "sorry guys, hard fork canceled" and the entire network just does as they say. That is not decentralization, but they have many nodes.

Ethereum nodes are irrelevant, typically they are not full nodes and the whole Ethereum thing and its governance issues is a joke, I admit, still irrelevant tho.
More full nodes, means more decentralization not absolute decentralization because we have pools and miners to take care of as well.

• Improved software quality because of significant reduction in need for downward compatibility.

Just about everything that is currently needed for consensus validation would be needed in the UTXO commitment model. In fact, this would cause more bloat because now we have to handle a new rule: UTXO commitments. All of the other things needed for backwards compatibility like non-segwit outputs still need to be maintained.

Handling UTXO commitment is trivial and opens doors to possibilities for having a much cleaner approach to downward compatibility because obsolete transaction types do not need to be validated. Spending UTXOs needs a downward compatible scrypt processing engine, I accept but it is not true for validation routine.

cons:

• vulnerability to ultra-long/complete chain rewrite attacks which are not practical anyway
• nothing else

You forgot a few:

• Increased trust in third parties

And if you are talking about UTXO commitments in every block, there's more cons:

• Additional time to validate and produce blocks due to the need to hash the UTXO set
• Issues with commitments themselves where they do not necessarily commit to all UTXOs or collide and commit to UTXOs that do not exist

Now I'm not saying the UTXO commitments are universally bad. It is an active area of research and someone may come up with a breakthrough which allows us to do this kind of pruning trustlessly. However, as it is now, UTXO commitments introduce more trust in others, and pruning the blockchain so that it is just an initial UTXO set from which blocks are built on is simply introducing too much trust to the system.

But UTXO commitments will certainly be useful even if they introduce more trust. Instead of pruning the blockchain to some initial state, they would allow for a faster sync. You can do a sort of Hybrid sync where you use a UTXO set initially and check it against UTXO commitment in blocks so that you can be synced very quickly. Then in the background the blockchain can be downloaded and checked. This would allow the best of both worlds: you can have a faster sync and reduce your node's resource usage, and the full history is still verifiable and you can verify that the UTXO set you received initially is correct. This would be optional: for those who want to have a faster sync and don't care that they are trusting others, they can use the UTXO commitments. For those who want a faster sync and are okay with initially trusting but later verifying the UTXO set, they can use the hybrid sync. And for those who want to have the least amount of trust in others and to verify everything, they can do the full sync of the blockchain.

Now you are speaking a bit more rigorously: I maintain that your "need for trust" issue is not correct though I admit that there is something to pay when you get such a huge utility, unlike what you say, it is not about trust, it is about desired security level against long range attacks: when users feel there is a more than one billion dollars incentive for adversarie to commit they need to tune for 20K+ number of commitments and pruning height.

[achow101]

I maintain that your "need for trust" issue is not correct though I admit that there is something to pay when you get such a huge utility, unlike what you say, it is not about trust, it is about desired security level against long range attacks

A large part of the desired security level against long range attacks is reducing the need for trust. I do not think that there is enough utility to be gained from cutting off blockchain history and using an initial state to warrant the decrease in security. Of course, this is just opinions between multiple people and no one is going to convince the other that they are correct. So I will stop responding to you.

[aliashraf]

I maintain that your "need for trust" issue is not correct though I admit that there is something to pay when you get such a huge utility, unlike what you say, it is not about trust, it is about desired security level against long range attacks

A large part of the desired security level against long range attacks is reducing the need for trust. I do not think that there is enough utility to be gained from cutting off blockchain history and using an initial state to warrant the decrease in security. Of course, this is just opinions between multiple people and no one is going to convince the other that they are correct. So I will stop responding to you.

Good chat,  it is obviously up to you to continue this discussion, I respect your choice anyway.

Cost of a long range attack increases linearly with its range. Security against such an attack is achieved by the basic game theoretic assumption of  bitcoin: rational behavior of participants. Trust is not relevant here, neither legacy protocol nor the version supporting UTXO commitment is based on trust and/or  secures the network using trust, essentially.

[cellard]

It's always going to be a tradeoff. The most hardcore users aren't going to buy that cutting off a chunk of the blockchain is safe. As long as it was optional then let other people do it, but don't ruin it for those that want to sync since the genesis block. In any case from what I can remember reading when I asked the same thing a while ago what I think I was told is that basically you couldn't sync without doing it from scratch anyway. Correct me if im wrong but you cannot run a node in pruned mode unless you sync from scratch even to this day (you can save a ton of space by not storing the entire blockchain as it cuts as it downloads but it must be downloaded and validated from scratch). I think at 1MB this is not a problem, however with bigger blocksizes I wonder if in in the future it would become a problem trying to sync from scratch but thus far is not an issue.

[aliashraf]

It's always going to be a tradeoff. The most hardcore users aren't going to buy that cutting off a chunk of the blockchain is safe. As long as it was optional then let other people do it, but don't ruin it for those that want to sync since the genesis block. In any case from what I can remember reading when I asked the same thing a while ago what I think I was told is that basically you couldn't sync without doing it from scratch anyway. Correct me if im wrong but you cannot run a node in pruned mode unless you sync from scratch even to this day (you can save a ton of space by not storing the entire blockchain as it cuts as it downloads but it must be downloaded and validated from scratch). I think at 1MB this is not a problem, however with bigger blocksizes I wonder if in in the future it would become a problem trying to sync from scratch but thus far is not an issue.

As I've extensively discussed it above-thread and elsewhere, it is absolutely possible for nodes to decide about the length of the chain they want to download (in boot process) and maintain because bitcoin essentially is a consensus mechanism for the state of a ledger such that as time passes this consensus gets more and more stronger and unforgeable. Taking advantage of this inherent property, it would be trivial to download an old (and secure) enough representation of the state (the UTXO at a given height) instead of rewinding the tape to big bang.

[Abdussamad]

So, I got into an argument with a friend and we were discussing on scaling problems of the blockchain.
As the blockchain gets bigger and bigger, why don't we just save the state of the blockchain (by which I mean all the utxos) every year and hash the preceding blocks, so we know that this is the correct state and erase these blocks afterwards?

How do you know the hash of the preceding blocks is the true hash? You will have to trust someone. Bitcoin is all about not having to trust anyone.

[aliashraf]

So, I got into an argument with a friend and we were discussing on scaling problems of the blockchain.
As the blockchain gets bigger and bigger, why don't we just save the state of the blockchain (by which I mean all the utxos) every year and hash the preceding blocks, so we know that this is the correct state and erase these blocks afterwards?

How do you know the hash of the preceding blocks is the true hash? You will have to trust someone. Bitcoin is all about not having to trust anyone.

A long enough chain is valid by virtue of its own accumulated work, it is how pruning makes sense. Pruned nodes are doing fine right now in bitcoin ecosystem without any vulnerability due to trust because they don't have trust to any source unlike spv wallets.

At the current state of the art, to have a bitcoin pruned full node, you need to download full blockchain, starting from genesis block (bootstrap) it is how your node generates and maintains a UTXO hence becomes eligible for removing a considerable amount of the history depending on your choice of pruning height.
Above-thread I've tried to support UTXO Commitment ideas that imply adding hash commitments in blocks to the state of database.
As a result pruned nodes no longer need to download the full history because they would be able to query the actual UTXO directly which has enough commitments, no trust issue is raised this way because of the hash commitments.

[j4k0b]

Wow these are a lot of answers, thank you very much!
So, I get that the miners could introduce a wrong hash of the utxo set, but I don't quite understand how that would be done without anyone noticing. So let's say we implement it in a way that miners first commit to a utxo set by including its hash in a block and n blocks after that ( choose a high enough n so that it is practically impossible to change that block ) we attach the utxo set to the block. This way when the hash of the utxo set is put into a block everybody could verify whether it is correct. If it's not nodes will reject that block, if it is correct nodes will accept it. Then when the utxo set is attached to the block n blocks after the one with its hash in it, nodes could delete the now obsolete blocks and the history can't be changed.

PS: If you know that these ideas have been discussed before, could you give me a source where I could find the discussion or a special term for such kind of proposal which I can search for?