Topic: Security Risks in downloading the whole Bitcoin Blockchain from external srces?? (Read 725 times)

I've been thinking about creating a pruned_Bitcoin.zip for a while now. It will be around 3 GB (uncompressed), as I think the chainstate directory has to be included. All I need to do this, is a simple VPS.
But, I see two main problems:
1. Anybody who downloads it has to trust me. Unlike a full blockchain, a pruned blockchain can't be rescanned.
2. I could set up a VPS, but I don't have the skill to be absolutely sure it won't get compromised. Or the hoster could give someone access after social engineering.

The reason I would like to offer it though, is that Bitcoin Core is the most basic wallet, and I consider it a good thing if more people are able to verify their own transactions.
Recently, someone gave me a zip of all 20 million Bitcoin addresses with balance. Read that again: just 20 million addresses! Uncompressed, that's just 800 MB. If you'd add details on all individual outputs, it may rise to a few GB.
If - in the future - a pruned Bitcoin Core can read TXID-data from just a database, you don't have to prune all blocks, you just have to keep a record of all balances. Once you have that, 10 GB may be enough to be able to verify all transactions in existing wallet.dat files.

The minimum for a pruned blockchain is 550 blocks (4 days) of data. If you'd download a pruned blockchain as a .zip, you could just wait four days to have all downloaded data replaced by new data already. I'm not sure how secure that would be though.

I think Core would still force a reindex even if the wallet.dat is newly generated. Without all the blocks, the client will not be able to retrieve all the transactions associated with a specific address.[/quote]
I can tell you from personal experience that a pruned blockchain doesn't require a rescan to create a new wallet. There's no point to check if new addresses hold any balance.

I think one concern here would be when Bitcoin Core is reading and parsing the block chain.  What if there is an undetected buffer overflow (stack or heap etc) or other issue in Bitcoin Core (or any other program that reads the block chain)?  This could provide an opening for attack.  It could then run an executable that was left in the block directory or code in the 'block' itself.  Buffer overflows have been a problem for decades and while Bitcoin Core is well tested, it is not perfect.  (Libraries used by Core have had buffer overflow issues in the past - e.g. the UPnP one several years ago.)

Or it could be a simple as a "ReadMe.txt.exe" file in the directory.  If only a small percentage of people on whatever OS click it without paying attention, you could have a lot of problems. 

Or (as was touched on above) suppose the archive itself is replaced with some type of malware? 

It is best to practice defensive usage so as to avoid finding out the hard way that there was an issue.

I don't get it. The user never runs anything and the blocks are merely copied to the data directory. Nothing is run in the process, not even when Core is opened, it only reads from the blocks. I've never heard of any malware that could be executed by itself, without the user's intervention.

Either that, or its in zip/rar format and theres pretty much no way for a malware to be executed either.

I think you've answered your own question there.

Spendulus, I understand that signatures are the only reliable proof that the database files are really valid and correct. Is there a way I could add such a signature for my upload if all I remember it was created from the actual blockchain as for the morning of October 24th?

NO.

Virus scanners routinely find (falsely) sections of the blockchain that they consider viruses. These are false positives, but rest assured that code can be disguised, such that it can be assembled later, without having a virus signature. That would be a false negative from the scanner.

In addition, it would be ridiculously easy to include extra files in the directories built, said files being outside of the blockchain.

You asked a question regarding an independent blockchain download method, and I answered your question. The proof of the integrity and safety of the download is the signature. Here it appears one would need several signatures, one for each subdirectory and one for the overall folder.

If this is not understood I'll be happy to elaborate.

I think he was also saying one could hide malicious software inside the directory that stores the block chain files which wouldn't be detected by Bitcoin Core since it only looks at the blocks themselves.  Not to mention virus scanners should NOT be relied upon.  Often people are told to exclude the block directory due to false positives which would mean anything else in there would be missed even if the scan was reliable.

Another problem is that downloading this should be slower than just starting Bitcoin Core and letting it sync since it will sync from multiple nodes in parallel.  A monolithic block chain download hasn't been advisable for at least 3 major versions.

I've explained that the full syncingof of the blockchain would be much faster than in the usual way.
When I was starting my Bitcoin Core full node it took weeks to download the blockchain.
And the bottleneck was not in my internet bandwidth or my cpu or ram. The bottleneck was the number of active, accepting incoming connections full nodes, from where my node could download the blockchain (that's how I see it

The risks are there, why take the chance?

My upload does not include the Bitcoin core application itself. There is exclusively my 0.15.0.1 Core's data directories (except wallet.dat and debug.log

Spendulus, if I understand you right, you mean there is a danger that one could hide some malicious soft inside the blockchain files. Well, of course every internet download should be scanned with an antivirus.

That would be a danger for the user, his computer and so on.

What I was concerned most of all was   in no case, by no means to cause any harm to the Bitcoin Blockchain network, if there suddenly appeared some full nodes with a malicious wrong database (suppose some malifactors use the hint and uploaded some corrupted databases

Well, couldn't a malicious payload be embedded in the database? Something that could be lay dormant until a signal is received to activate? Think of it this way. The database resides in directories. Right now I can add files to those directories, and Core does not care. It's only operating on the files it is directed to. The additional files are undetected.

What you need here is a verifiable signature on the files which proves they match byte for byte with the actual master database.

Everyone should know the fallacy of downloading and using files without verifying the signature.

A classic way of injecting a payload into user computers is to start with a "thing they want," add the malicious payload, then prompt in various ways for them to download the "thing they want." In the case of bitcoin users, the most glaring example would be a compromised wallet.

Here we have a blockchain database. Suppose Bad Guy (BG) sees a lot of people dl'ing your database, then he grabs a user id one character off, creates a download link almost identical, and offers some appeal to greed to induce downloads. Before anyone catches it there are thousands of downloads.

Verification of the file signature prevents this. If Core is downloaded and it's signature verified, then that verified code is used to download the blockchain, one can say that the entire system is good.

Guys, thank you very much for your replies.

You've calmed me down a little. I was much worried that instead of helping with fast starting new full nodes I might do some harm on the contrary.

So, I will not delete the uploaded blockchain yet, it might help some people with a pretty fast internet conception to launch their full nodes faster than if they did it in the usual way.

But I'd like to remind those with a pretty slow download internet connection that they could gain almost no advantages downloading my upload, they are better to let their Bitcoin Core full node sync itself in its usual way.

I wouldn't say that the security risk is huge. There is still a security risk such that you could potentially change all the blocks out and it would potentially be valid. The client does not verify the entire Blockchain again at start up and only verifies the last few hundred blocks IIRC. However, you would also have to isolate the client from the mainnet unless your modified blockchain has the longest chain difficultywise. Its not very effective.

I think Core would still force a reindex even if the wallet.dat is newly generated. Without all the blocks, the client will not be able to retrieve all the transactions associated with a specific address.

It would be great if there was a pruned blockchain available for download.

But the only way it could work with maximum security would be if it was somehow verified by the network. For example so that enough miners have validated it  and signed that it is correct.
This would solve the problem of needing to download 140GB of data ... because pruned blockchain could fit in 1 GB

I do not really see a big security risk in downloading the blockchain from you. Even if you had altered the blockchain somehow and it could theoretically fork the chain, it would only work if the MAJORITY of nodes and miners would start using your version of blockchain, and that is never going to happen.

Hello everyone,

Recently I uploaded the whole Bitcoin Core blockchain database to my Google Drive, see details here:
https://bitcointalksearch.org/topic/whole-bitcoin-core-015-blockchain-database-on-google-drive-2321650

But later a wise forum's hero member miguelmorales85 expressed deep concern about security risks in downloading and using such a blockchain database in one's Bitcoin Core application.

I am absolutely sure SECURITY RISKS are NEVER ACCEPTABLE in Bitcoin network!!!

I am still a newbie in blockchain technologies, so I'd ask smart technical guys to explain a little bit: are there actually any real security risks here??? What are they?

If yes, I will immediately delete the upload from the Google Drive