Author

Topic: Is it possible to run a full node without verifying the whole blockchain? (Read 453 times)

legendary
Activity: 2338
Merit: 10802
There are lies, damned lies and statistics. MTwain
<…>
I think @ETFbitcoin came up with a couple of good examples where the principal you mention was applied. I’ve found a couple more on the Beginners and Help board:

How to earn merit?? (bad example that I wished to include deliberately, for an undeserved merited question).
Bitcoin clarification needed, please
What is Escrow?

In my opinion, only the second case could deserve merit for the question, since it showed that the OP had some background on what he was asking about, and placed the question after thinking it through with a specific well versed focus (a bit similar to your full node question), and not a generic question with no prior research.

Questions can lead to answers in the line of analysis of scenarios, comprehension, real case usage, opinion, guidance and so on, but if it is elaborated not just on its own, but rather with a context that has been researched it can, as far as I can see, postulate to being merited. Simple questions on the other hand that denote an aroma of deliberate ignorance do not, even if the answers in the thread are merited in abundance.
sr. member
Activity: 868
Merit: 251
In my opinion it is possible but you you have a person, a friend or a part of your family, whom you can absolutely trust in this situation.
sr. member
Activity: 279
Merit: 435
Quote
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.
sr. member
Activity: 938
Merit: 452
Check your coin privilege
Quote
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.
sr. member
Activity: 279
Merit: 435
Quote
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.
legendary
Activity: 2898
Merit: 1823
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  Wink

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  Wink

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.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
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
sr. member
Activity: 938
Merit: 452
Check your coin privilege

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..
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
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.
sr. member
Activity: 938
Merit: 452
Check your coin privilege
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...
legendary
Activity: 1456
Merit: 1175
Always remember the cause!
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.
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
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.
sr. member
Activity: 938
Merit: 452
Check your coin privilege
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?
sr. member
Activity: 279
Merit: 435
Hi,

Quote
the full blockchain (~200GB?)
Yes, almost (cf https://www.blockchain.com/fr/charts/blocks-size).

Quote
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.

Quote
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 Wink.
legendary
Activity: 1456
Merit: 1175
Always remember the cause!
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  Wink

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  Wink
sr. member
Activity: 938
Merit: 452
Check your coin privilege
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.
Jump to: