Is it possible to run a full node without verifying the whole blockchain?

[KingZee]

I just recently decided to start running a full node, I get the long process of setting it up because bitcoin core has to download the full blockchain (~200GB?) to verify.

But I had a question, since we can run pruned mode, and limit the size of the data to the 550 latest blocks, isn't it hypothetically possible to bypass the whole verification process? Can't someone run bitcoin core, let it finish synchronizing with the network, and then just store the final state of bitcoind an replicate it on other machines? Thanks.

[1713481546]

1713481546

[1713481546]

1713481546

[aliashraf]

OP!
It is absolutely possible but with current bitcoin core client, you need to trust someone who has a verified-then-pruned blockchain installed. If you got one then you would be able to do it with no pain or regret.

Although, you could check your copy for consistency partially:

1- Download and reinstall client software from github.
2- Check your latest block hash with what reputable browsers report for the same height.
3- You need a "simple" script that uses bitcoin api that checks the blockchain you got on your copied node to be truly linked by previousblockhash field in json rpc call, getblock. You need to get each block in serialized mode and make an sha2 hash to check the block you get against the hash.

but it would never be helpful to get rid of the trust issue because you are vulnerable to UTXO manipulation by your trusted peer. Here is the thing, find someone you really, relly trust and don't pay attention to guys who will come here and make speeches about bitcoin being trustless, blah, blah, ... you are safe if you got a friend who is not part of a multi-billion dollars international conspiracy  

That said, it is definitively possible to make it a built-in trustless feature for bitcoin, bootstrapping from a UTXO backed by consensus. Stay tuned  

[darosior]

Hi,

the full blockchain (~200GB?)

Yes, almost (cf https://www.blockchain.com/fr/charts/blocks-size).

we can run pruned mode, and limit the size of the data to the 550 latest blocks

As you mentionned running a pruned node is just usefull to avoid taking too much place. A pruned node will keep the UTXO set, and in order to form it has to check every blocks since the first.
How could you get all these informations otherwise ? By trusting on or some peers ? If so, it's better not to run a node.

bypass the whole verification process? Can't someone run bitcoin core, let it finish synchronizing with the network, and then just store the final state of bitcoind an replicate it on other machines? Thanks.

The only truth on Bitcoin is what is written in the chain. The whole point of running a node is being kind of a new "witness" of that truth. How could you be sure of this truth if you trusted someone else ? You have to verify instead of trusting and that's what bitcoin-core is doing while you are synchronizing .

[KingZee]

Thanks @aliashraf and @darosior. I wasn't planning on downloading the pruned version from someone, but I did plan to start multiple full nodes and didn't want to go through the full process of verifying the chain again.

I see the point in being a new "honest" node, but I don't see the need of creating the chainstate from scratch, I'm sure that with thousands of nodes on the network, there isn't really a security risk. What's the worst case scenario? If a transaction is invalid it's going to be ignored, if a node has a different copy of the blockchain then it won't be able to verify any of the current blocks...

If I were to download a pruned copy from someone it would be very easy to see if it's legitimate or not, right?

[ranochigo]

I see the point in being a new "honest" node, but I don't see the need of creating the chainstate from scratch, I'm sure that with thousands of nodes on the network, there isn't really a security risk. What's the worst case scenario? If a transaction is invalid it's going to be ignored, if a node has a different copy of the blockchain then it won't be able to verify any of the current blocks...

Depends on how you see it. The attacker can easily fabricate a blockchain that has thousands of low difficulty block and that they could trick you into accepting transactions which are otherwise invalid with a simple MITM attack with sybil nodes. Transactions can be valid but they can be valid only on specific forks on the chain. You aren't validating the blockchain that you've received so the UTXO database could easily be fabricated still.

If I were to download a pruned copy from someone it would be very easy to see if it's legitimate or not, right?

No. It is simply impossible to verify its authenticity based on hashes of the file since the files are likely to have different hashes from various sources, though they may all not be malicious. The only way for you to verify is to verify each and every block by yourself.

[aliashraf]

If I were to download a pruned copy from someone it would be very easy to see if it's legitimate or not, right?

No, it wouldn't be that easy.The peer could easily manipulate the UTXO by inserting invalid rows and poisoning it for his future attacks.

The only possible mitigation would be improving the consensus layer to support UTXO commitment in blocks. Long story and you show little interest as I understand.

[KingZee]

Depends on how you see it. The attacker can easily fabricate a blockchain that has thousands of low difficulty block and that they could trick you into accepting transactions which are otherwise invalid with a simple MITM attack with sybil nodes. Transactions can be valid but they can be valid only on specific forks on the chain. You aren't validating the blockchain that you've received so the UTXO database could easily be fabricated still.

No. It is simply impossible to verify its authenticity based on hashes of the file since the files are likely to have different hashes from various sources, though they may all not be malicious. The only way for you to verify is to verify each and every block by yourself.

I didn't mean verification of the files, but to see if the blockchain I'm working on is the same as every other node.

Let's assume I downloaded a "fake" chain from another user. Let's also assume he knows my IP and that it's running as a forked node using his modified chain, if he sends me "fake" transactions and blocks, am I not going to be able to instantly see it? The difference between the future blocks that I'll be synchronising with and the blocks that are broadcasted by the hundreds of miners are impossible to be the same... So I really don't understand what you mean by your explanation.

This is the point I'm trying to make, if I download a pruned chain, and it can't validate the same blocks that every other node is validating, then it's fabricated. The latter fact can be easily verified, and once it is, further down the line becomes impossible for an attacker to send me "poisoned" txes...

[ranochigo]

I didn't mean verification of the files, but to see if the blockchain I'm working on is the same as every other node.

Ah I see. Yeah, you can't do it unless you want to validate every single stuff again.

Let's assume I downloaded a "fake" chain from another user. Let's also assume he knows my IP and that it's running as a forked node using his modified chain, if he sends me "fake" transactions and blocks, am I not going to be able to instantly see it? The difference between the future blocks that I'll be synchronising with and the blocks that are broadcasted by the hundreds of miners are impossible to be the same... So I really don't understand what you mean by your explanation.

In an MITM attack, the attacker would likely be able to control what you can see and what you can't. They can lead you on a separate network and they can send you blocks and transactions that are different from the mainchain. You won't be able to see any other blocks if the attacker can isolate you away from the others.

Given that the client does not always go back to use its blockchain after the initial synchronization and building of the chainstate, it is possible for only the chainstate to be modified and the client would not notice this at all.

This is the point I'm trying to make, if I download a pruned chain, and it can't validate the same blocks that every other node is validating, then it's fabricated. The latter fact can be easily verified, and once it is, further down the line becomes impossible for an attacker to send me "poisoned" txes...

At start up, the client does not validate every single block. The client stores the relevant information in the chainstate for which it can be fabricated. The attacker can modify the chainstate without affecting future blocks.

[KingZee]

In an MITM attack, the attacker would likely be able to control what you can see and what you can't. They can lead you on a separate network and they can send you blocks and transactions that are different from the mainchain. You won't be able to see any other blocks if the attacker can isolate you away from the others.

Given that the client does not always go back to use its blockchain after the initial synchronization and building of the chainstate, it is possible for only the chainstate to be modified and the client would not notice this at all.

I understand what you mean but I can't see the danger.. Mainly because even if bitcoind can't figure it out by itself because it's going to be connected to a network of forked nodes all controlled by the attacker, all it takes is for the user to view "getblockchaininfo" or "getblock someMainChainHash" to see that his client isn't on the main network...

Thanks a lot to you for trying to explain but it's just that I'm trying to think of the rationality behind an attacker doing such a thing, and how feasible it is in real life.. The amount of effort for an attacker to pull off something like this, and the possibilities of him being figured out are so massive, that I can't see any reason why I would be worried at all..

[ABCbits]

Thanks @aliashraf and @darosior. I wasn't planning on downloading the pruned version from someone, but I did plan to start multiple full nodes and didn't want to go through the full process of verifying the chain again.

If at least one of your full nodes isn't on pruned mode, then you could set all pruned full-node to always connect to your non-pruned full nodes. Assuming your full nodes isn't under attack, then MITM attack on pruned full-node would be far harder

You can use this guide https://bitcoin.stackexchange.com/a/41427 if you're interested

[Wind_FURY]

OP!
It is absolutely possible but with current bitcoin core client, you need to trust someone who has a verified-then-pruned blockchain installed. If you got one then you would be able to do it with no pain or regret.

Although, you could check your copy for consistency partially:

1- Download and reinstall client software from github.
2- Check your latest block hash with what reputable browsers report for the same height.
3- You need a "simple" script that uses bitcoin api that checks the blockchain you got on your copied node to be truly linked by previousblockhash field in json rpc call, getblock. You need to get each block in serialized mode and make an sha2 hash to check the block you get against the hash.

but it would never be helpful to get rid of the trust issue because you are vulnerable to UTXO manipulation by your trusted peer. Here is the thing, find someone you really, relly trust and don't pay attention to guys who will come here and make speeches about bitcoin being trustless, blah, blah, ... you are safe if you got a friend who is not part of a multi-billion dollars international conspiracy 

That said, it is definitively possible to make it a built-in trustless feature for bitcoin, bootstrapping from a UTXO backed by consensus. Stay tuned 

But why the need to complicate the process? OP can set "prune=10000" or lower, though I do not recommend it, unless it is absolutely necessary because of storage space, or bandwidth limitations.

[darosior]

OP can set "prune=10000" or lower, though I do not recommend it, unless it is absolutely necessary because of storage space, or bandwidth limitations.

He would still have to verify the chain, and that's what he doesn't want to do.

[KingZee]

OP can set "prune=10000" or lower, though I do not recommend it, unless it is absolutely necessary because of storage space, or bandwidth limitations.

He would still have to verify the chain, and that's what he doesn't want to do.

Yes.. Unfortunately I have to at this point, I couldn't find anywhere reasonable to get a chainstate.. I tried to download it from a node but I couldn't figure out how to view which one has a pruned copy and how to get it.. My linux server is at 60% now after 60 hours anyways, so I'll wait for it to sync and just upload the 550mb chainstate somewhere where I can re-use it later in case I'd like to run another node.

I still would like to hear if anyone has any answer to my last message, explaining to me a valid risk of a pruned chain downloaded from another valid bitcoin peer, assuming they have some sort of forked version of that chain. I'm genuinely not convinced.

[darosior]

I still would like to hear if anyone has any answer to my last message, explaining to me a valid risk of a pruned chain downloaded from another valid bitcoin peer, assuming they have some sort of forked version of that chain. I'm genuinely not convinced.

I think you see it from kind of a ""user"" point of view, what we could call a "leecher" on BitTorrent. But as a Bitcoin node you also seed what you assert to be the truth, other node, some services, some user could rely on you to get information about the network and, by being a node which have fully validated the history since 2009, you can assert these informations to be the truth. You cannot assert this is the absolute truth if you trusted someone instead of verifying. For sure if you are not permitting your node to share information, this is far less risky but that's not how P2P should work.