<p>This is certainly technically possible (run with <code>-detachdb</code> and then copy the database directory), but the question is whether you would want this.</p>

<p>First, take a step back. Bitcoin is designed to work with reasonable security on lightweight nodes (see "Simplified payment verification" in <a href="http://bitcoin.org/bitcoin.pdf" rel="nofollow">Satoshi's paper</a>). The only trust lightweight nodes require is that the chain with the most work in it, also contains valid transactions. Such lightweight nodes require a few megabytes of downloads to synchronize, and cause almost no CPU or disk load. Examples of such node implementations include <a href="http://multibit.org/" rel="nofollow">Multibit</a> or <a href="https://play.google.com/store/apps/details?id=de.schildbach.wallet" rel="nofollow">Bitcoin Wallet for Android</a>.</p>

<p>The reason this is possible, is because lightweight nodes assume that there are full nodes which do verify everything, and that no miner will risk creating blocks that contain invalid transactions (a very reasonable assumption, as in a sane network, such blocks will be ignored by everyone else). These full nodes form the security backbone of the network, and as they verify everything, they essentially require zero trust. This is something of a core property of Bitcoin, which exists in almost no other payment system: the privilege of not needing to trust anyone.</p>

<p>If you're going to download a pre-indexed block chain, you are giving up that privilege. You're essentially going to trust one person (maybe a few, if you actually bother checking signatures) to tell you which transactions in Bitcoin's history were valid. This is a much stronger assumption than the one you make when running a lightweight client. If someone were able to corrupt (even unintentionally!) such a download, and it was used by many people, the risk could be a forked network. This could be a disaster.</p>

<p>So, if you think your system cannot handle the current load of running a full node, please just run a lightweight one. If lightweight software doesn't offer the features you want, encourage them to implement them - they'll be needed as time grows.</p>

<p>As a side note, the next release (0.8) of Bitcoind/Bitcoin-Qt should be <strong>much</strong> faster, especially on hardware with slow input/output.</p>

CC BY-SA 3.0
2012-11-24T17:31:35.543Z
So there is basically no security risk in running a lightweight client—looks like I’m an idiot.
Profpatsch
CC BY-SA 3.0
2012-11-24T17:57:41.000Z
@Profpatsch: Not a significant one, no. But this relies on the assumption that there are also many full nodes.
Meni Rosenfeld
CC BY-SA 3.0
2012-11-24T18:01:05.170Z
There is a significant difference between not trusting anything, and trusting the longest chain to only contain valid transactions. Whether you want to risk this is an economic question. But it's certainly a smaller assumption than accepting a pre-indexed database.
Pieter Wuille
CC BY-SA 3.0
2012-11-24T21:04:56.907Z
Since that question didn’t exist and I think more people want to know, I asked it here: http://bitcoin.stackexchange.com/questions/5478/should-an-end-user-download-the-whole-blockchain-or-is-a-lightweight-client-s
Profpatsch
CC BY-SA 3.0
2013-06-11T21:48:14.860Z
I have slight problem with this answer. Assume the following that I download a faulty(tampered with) block chain. Won't the coins I generate (assuming it will succeed) be rejected by the bitcoin peers? Excuse my ignorance I am just trying to get my head around this.
Sydwell
CC BY-SA 3.0
2013-06-11T22:13:22.173Z
If you download a faulty block chain, your own client won't import it even. If you download a faulty pre-indexed database (which contains not the chain itself, but the resulting set of unspent coins), there are multiple dangers. They can let you believe certain incoming invalid transactions are valid (which you don't want as a merchant), and other nodes will reject those indeed - but maybe you already shipped them goods in return? The larger problem is when many nodes get the same faulty database... then they may end up on a fork of their own, and think the real world is wrong.
Pieter Wuille
CC BY-SA 3.0
2012-11-24T17:26:52.817Z
2012-11-24T17:26:52.817Z
Pieter Wuille
<p>You can choose where to download from!</p>

<p>Please see <a href="https://bitcoin.stackexchange.com/questions/12001/what-is-the-fastest-possible-way-to-download-the-blockchain">What is the fastest possible way to download the blockchain?</a></p>

<p>I described how to tell the bitcoin client to connect to custom nodes.
This way you can tell bitcoin to connect to the major hub nodes for example.</p>

<p>This has 2 advantages:</p>

<p>A) full control who to trust</p>

<p>B) Blazing fat bitcoin blockchain download.</p>

CC BY-SA 3.0
2013-07-05T20:39:34.667Z
2013-07-05T20:39:34.667Z
2017-04-13T12:47:33.743Z
Aurigae
<p>There already are downloadable versions of the blockchain. There's no problem in principle in having them GPG-signed by several trusted people. However:</p>

<ol>
<li><p>It somewhat weakens security. With the software itself you can trust the signatures <em>and</em> you can inspect the code. With blockchain data inspecting it is infeasible.</p></li>
<li><p>Future versions will use a different DB format which allows for much faster verification, so there will not be much advantage for a system where verification is obviated but downloading the data is still needed.</p></li>
<li><p>In the long-term, end users will not use a full client, but rather (at best) an SPV client which does not need to download or verify the entire blockchain.</p></li>
</ol>

CC BY-SA 3.0
2012-11-24T16:47:09.170Z
So bitcoind is utter crap, nuff said?
Isn’t an SPV client even more insecure that downloading a blockchain verified by several people with their gpg keys and thus, their email addresses?
Profpatsch
CC BY-SA 3.0
2012-11-24T17:56:32.400Z
@Profpatsch: I didn't say that. Full nodes are vital and their performance will improve soon. But they are not intended to be used by end-users.
Meni Rosenfeld
CC BY-SA 3.0
2012-11-24T18:07:37.663Z
@profpatsch SPV is not less secure.  It has less features, but those features aren't needed by most end users.
Stephen Gornick
CC BY-SA 3.0
2012-11-24T20:24:47.510Z
Of course it is less secure... it does not verify transactions, only proof of work. For zero-confirmation transactions the security difference is very significant. Deeper in the chain... less so.
Pieter Wuille
CC BY-SA 3.0
2013-06-11T21:40:31.503Z
I have just asked a very similar question. Where are those downloaded versions?
Sydwell
CC BY-SA 3.0
2012-11-24T16:29:50.827Z
2012-11-24T16:29:50.827Z
Meni Rosenfeld
<p>As of November 2012, the blockchain is nearly 3 GB in size with a near-linear growth of about 500 MB/month (cut from exponential growth by the hard-coded block size limit, I guess).</p>

<p>I want to install Bitcoin on my average notebook:
Downloading and verifying the <a href="http://eu2.bitcoincharts.com/blockchain/" rel="nofollow noreferrer">latest bootstrap.dat from Bitcoincharts</a> took some hours (5–9, I guess), but that was only 2.3 GB! Now, I’ve been waiting for Bitcoin to catch up on the last 2–3 months, in which blocks have been considerably bigger and each block takes about 5 seconds of being processed, with my CPU at ~25% and my hard drive at max workload.</p>

<p>This is, to be put lightly, unsustainable.</p>

<p>We need a system, in which an already verified blockchain can be downloaded and directly copied to the bitcoin folder, maybe in an incremental form.
The source has to be trusted, for this, one needs a verifying system in which everyone can control the correctness of the blockchain and then sign it, I’d propose to use gpg keys for this.</p>

<p>The source can then be distributed via server-backed torrent, for example.</p>

<p>Is this technically possible and how?</p>

<p>Edit: Since I approached this with a wrong mindset, I posted kind of a follow-up question about the security risks of lightweight clients. <a href="https://bitcoin.stackexchange.com/questions/5478/should-an-end-user-download-the-whole-blockchain-or-is-a-lightweight-client-s">Should an end-user download the whole blockchain? Or is a “lightweight” client sufficient?</a></p>

<blockchain><bitcoind><bitcoin-core><verification>
Would it be possible to provide a downloadable blockchain that is updated and verified by a mass of people?
Profpatsch
# Would it be possible to provide a downloadable blockchain that is updated and verified by a mass of people?

(Asked by: username_0 on 2012-11-24)

As of November 2012, the blockchain is nearly 3 GB in size with a near-linear growth of about 500 MB/month (cut from exponential growth by the hard-coded block size limit, I guess).

I want to install Bitcoin on my average notebook:
Downloading and verifying the [latest bootstrap.dat from Bitcoincharts](http://eu2.bitcoincharts.com/blockchain/) took some hours (5–9, I guess), but that was only 2.3 GB! Now, I’ve been waiting for Bitcoin to catch up on the last 2–3 months, in which blocks have been considerably bigger and each block takes about 5 seconds of being processed, with my CPU at ~25% and my hard drive at max workload.

This is, to be put lightly, unsustainable.

We need a system, in which an already verified blockchain can be downloaded and directly copied to the bitcoin folder, maybe in an incremental form.
The source has to be trusted, for this, one needs a verifying system in which everyone can control the correctness of the blockchain and then sign it, I’d propose to use gpg keys for this.

The source can then be distributed via server-backed torrent, for example.

Is this technically possible and how?

Edit: Since I approached this with a wrong mindset, I posted kind of a follow-up question about the security risks of lightweight clients. [Should an end-user download the whole blockchain? Or is a “lightweight” client sufficient?](https://bitcoin.stackexchange.com/questions/5478/should-an-end-user-download-the-whole-blockchain-or-is-a-lightweight-client-s)

**Tags:** blockchain, bitcoind, bitcoin-core, verification


---

## 3 answers

### Answer by username_2 on 2012-11-24. Score: 4 | Accepted answer

There already are downloadable versions of the blockchain. There's no problem in principle in having them GPG-signed by several trusted people. However:

1. It somewhat weakens security. With the software itself you can trust the signatures *and* you can inspect the code. With blockchain data inspecting it is infeasible.
2. Future versions will use a different DB format which allows for much faster verification, so there will not be much advantage for a system where verification is obviated but downloading the data is still needed.
3. In the long-term, end users will not use a full client, but rather (at best) an SPV client which does not need to download or verify the entire blockchain.

> **Comments:**
> **username_0**: So bitcoind is utter crap, nuff said? Isn’t an SPV client even more insecure that downloading a blockchain verified by several people with their gpg keys and thus, their email addresses?  
> **username_2**: @username_0: I didn't say that. Full nodes are vital and their performance will improve soon. But they are not intended to be used by end-users.  
> **username_5**: @username_0 SPV is not less secure.  It has less features, but those features aren't needed by most end users.  
> **username_1**: Of course it is less secure... it does not verify transactions, only proof of work. For zero-confirmation transactions the security difference is very significant. Deeper in the chain... less so.  
> **username_3**: I have just asked a very similar question. Where are those downloaded versions?  

---

### Answer by username_1 on 2012-11-24. Score: 2

This is certainly technically possible (run with `-detachdb` and then copy the database directory), but the question is whether you would want this.

First, take a step back. Bitcoin is designed to work with reasonable security on lightweight nodes (see "Simplified payment verification" in [Satoshi's paper](http://bitcoin.org/bitcoin.pdf)). The only trust lightweight nodes require is that the chain with the most work in it, also contains valid transactions. Such lightweight nodes require a few megabytes of downloads to synchronize, and cause almost no CPU or disk load. Examples of such node implementations include [Multibit](http://multibit.org/) or [Bitcoin Wallet for Android](https://play.google.com/store/apps/details?id=de.schildbach.wallet).

The reason this is possible, is because lightweight nodes assume that there are full nodes which do verify everything, and that no miner will risk creating blocks that contain invalid transactions (a very reasonable assumption, as in a sane network, such blocks will be ignored by everyone else). These full nodes form the security backbone of the network, and as they verify everything, they essentially require zero trust. This is something of a core property of Bitcoin, which exists in almost no other payment system: the privilege of not needing to trust anyone.

If you're going to download a pre-indexed block chain, you are giving up that privilege. You're essentially going to trust one person (maybe a few, if you actually bother checking signatures) to tell you which transactions in Bitcoin's history were valid. This is a much stronger assumption than the one you make when running a lightweight client. If someone were able to corrupt (even unintentionally!) such a download, and it was used by many people, the risk could be a forked network. This could be a disaster.

So, if you think your system cannot handle the current load of running a full node, please just run a lightweight one. If lightweight software doesn't offer the features you want, encourage them to implement them - they'll be needed as time grows.

As a side note, the next release (0.8) of Bitcoind/Bitcoin-Qt should be **much** faster, especially on hardware with slow input/output.

> **Comments:**
> **username_0**: So there is basically no security risk in running a lightweight client—looks like I’m an idiot.  
> **username_2**: @username_0: Not a significant one, no. But this relies on the assumption that there are also many full nodes.  
> **username_1**: There is a significant difference between not trusting anything, and trusting the longest chain to only contain valid transactions. Whether you want to risk this is an economic question. But it's certainly a smaller assumption than accepting a pre-indexed database.  
> **username_0**: Since that question didn’t exist and I think more people want to know, I asked it here: http://bitcoin.stackexchange.com/questions/5478/should-an-end-user-download-the-whole-blockchain-or-is-a-lightweight-client-s  
> **username_3**: I have slight problem with this answer. Assume the following that I download a faulty(tampered with) block chain. Won't the coins I generate (assuming it will succeed) be rejected by the bitcoin peers? Excuse my ignorance I am just trying to get my head around this.  
> **username_1**: If you download a faulty block chain, your own client won't import it even. If you download a faulty pre-indexed database (which contains not the chain itself, but the resulting set of unspent coins), there are multiple dangers. They can let you believe certain incoming invalid transactions are valid (which you don't want as a merchant), and other nodes will reject those indeed - but maybe you already shipped them goods in return? The larger problem is when many nodes get the same faulty database... then they may end up on a fork of their own, and think the real world is wrong.  

---

### Answer by username_4 on 2013-07-05. Score: 1

You can choose where to download from!

Please see [What is the fastest possible way to download the blockchain?](https://bitcoin.stackexchange.com/questions/12001/what-is-the-fastest-possible-way-to-download-the-blockchain)

I described how to tell the bitcoin client to connect to custom nodes.
This way you can tell bitcoin to connect to the major hub nodes for example.

This has 2 advantages:

A) full control who to trust

B) Blazing fat bitcoin blockchain download.


---

