The fact that you make this statement shows you did not grasp any of the point I was making.
The Pirate Who Can't Be Named

I think you fail to see that there are several ways to deal with the growing UTXO problem. Here, I will describe just one.

UTXO commitments store a hash of a Merkle tree or similar structure containing the UTXO set in the coinbase of a block.

A validating node after a UTXO commitment soft fork can choose to download only block headers and the blockchain head’s coinbase transaction. A rule of the P2P network protocol could state that a transaction must include the outputs it spends as well as partial Merkle trees towards the latest UTXO commitment. This means that although a transaction would take a larger amount of bandwidth, as it has to be broadcast alongside its ancestors, the validating node would not need to store the UTXO set.

Now we can go through the whole technical discussion about how this changes Bitcoin’s security model, and we can certainly have a lovely debate on the subject and consider many alternative versions of UTXO commitments with different levels of compromise. Also, even in a post-UTXO-commitment world, there is nothing but time, memory, CPU and archive node availability keeping you from downloading the whole chain from Genesis and verifying everything, even if just to throw the UTXO set away in the end and perform validations from then on using the commitment hash.

At this moment I believe I should have proven my point to your satisfaction.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.