Topic: Why don't we prune to scale? - page 2. (Read 627 times)

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.

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.

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

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.

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.

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!

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.



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.


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.

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) :

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?

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

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?