<p>A 30 days old chainstate database does not make sense. Either you have the chainstate completely, and are able to do full validation, or you don't, and you can't validate at all. There is no middle ground of only validating recent transactions, as any transaction you encounter with unknown inputs could either be fraudulent or created more than 30 days ago, and you'll have no way to tell without a full chainstate.</p>

<p>So, either you don't need full validation, and you can use a number of lightweight clients instead, or you do, and you'll either need to build the chainstate yourself by synchronizing history, or copying from a source you trust.</p>

<p>Please don't go download a chainstate from a random place on the Internet though. They can introduce arbitrarily many coins assigned to themselves, and your client would accept them. If many people started running nodes using the same chainstate 'copy' such transactions could even get into blocks, and cause forks in the best case, and theft in the worst case.</p>

CC BY-SA 3.0
2015-12-02T19:10:05.373Z
I'm working on a prototype/PoC of the protocol client for my thesis. In the long run, the software will run on full blockchain, but first I quickly want to run some performance tests and test the general idea. Believe me, I have analyzed my needs, and ATM a reasonably recent chainstate is all I need.
A. Robertson
CC BY-SA 3.0
2017-08-26T12:42:08.327Z
How do you know OP wants to transact? He clearly stated, "for my purposes". Could be "count average block time which isn't provided by blockchain.info"
Tankman六四
CC BY-SA 3.0
2015-12-02T18:15:29.897Z
2015-12-02T18:40:47.400Z
2015-12-02T18:40:47.400Z
Pieter Wuille
<p>Is it possible to download a recent snapshot of the chainstate database?</p>

<p>I'm running bitcoind (v. 0.11.8) on a machine with ~1mb/s download speed. After my client reached 300000 blocks, the synchronization is going insanely slow. I suspect it's because verification is very slow. The bitcoind processs is using nearly 100% CPU. However, for my purposes I only need a reasonably recent (i.e., up to 30 days old) chainstate database.</p>

CC BY-SA 3.0
2015-12-05T17:07:16.300Z
I can give you a copy if you want to contact me privately.  You can find my email address on my website, via my profile.  I don't really want to spend the time/bandwidth to keep it public and updated, though.  Obviously you can't be sure that I won't try to falsify it, but it sounds like this is just for testing purposes so maybe that's okay.
Nate Eldredge
CC BY-SA 4.0
2018-10-22T00:00:30.167Z
@NateEldredge Don't full-node bitcoin clients keep their chainstate database updated automatically?  If A. does (did) contact you privately would (did) you just recursively compress the "chainstate" folder and send that to him?  I ask because if that's how simple it is, I have an idea to make that concern you mentioned ("you can't be sure that I won't try to falsify it") go away.  And if that idea works really well, there could be a lot more validating nodes because they wouldn't need the full blockchain.
Dave Scotese
CC BY-SA 4.0
2018-10-22T00:02:02.193Z
Yes, that was my plan.
Nate Eldredge
<transactions><bitcoind><synchronization><database><bootstrap.dat>
Chainstate database for download
A. Robertson
# Chainstate database for download

(Asked by: username_0 on 2015-12-02)

Is it possible to download a recent snapshot of the chainstate database?

I'm running bitcoind (v. 0.11.8) on a machine with ~1mb/s download speed. After my client reached 300000 blocks, the synchronization is going insanely slow. I suspect it's because verification is very slow. The bitcoind processs is using nearly 100% CPU. However, for my purposes I only need a reasonably recent (i.e., up to 30 days old) chainstate database.

**Tags:** transactions, bitcoind, synchronization, database, bootstrap.dat

> **Comments:**
> **username_1**: I can give you a copy if you want to contact me privately.  You can find my email address on my website, via my profile.  I don't really want to spend the time/bandwidth to keep it public and updated, though.  Obviously you can't be sure that I won't try to falsify it, but it sounds like this is just for testing purposes so maybe that's okay.  
> **username_2**: @username_1 Don't full-node bitcoin clients keep their chainstate database updated automatically?  If A. does (did) contact you privately would (did) you just recursively compress the "chainstate" folder and send that to him?  I ask because if that's how simple it is, I have an idea to make that concern you mentioned ("you can't be sure that I won't try to falsify it") go away.  And if that idea works really well, there could be a lot more validating nodes because they wouldn't need the full blockchain.  
> **username_1**: Yes, that was my plan.  

---

## 1 answers

### Answer by username_3 on 2015-12-02. Score: 2

A 30 days old chainstate database does not make sense. Either you have the chainstate completely, and are able to do full validation, or you don't, and you can't validate at all. There is no middle ground of only validating recent transactions, as any transaction you encounter with unknown inputs could either be fraudulent or created more than 30 days ago, and you'll have no way to tell without a full chainstate.

So, either you don't need full validation, and you can use a number of lightweight clients instead, or you do, and you'll either need to build the chainstate yourself by synchronizing history, or copying from a source you trust.

Please don't go download a chainstate from a random place on the Internet though. They can introduce arbitrarily many coins assigned to themselves, and your client would accept them. If many people started running nodes using the same chainstate 'copy' such transactions could even get into blocks, and cause forks in the best case, and theft in the worst case.

> **Comments:**
> **username_0**: I'm working on a prototype/PoC of the protocol client for my thesis. In the long run, the software will run on full blockchain, but first I quickly want to run some performance tests and test the general idea. Believe me, I have analyzed my needs, and ATM a reasonably recent chainstate is all I need.  
> **username_4**: How do you know OP wants to transact? He clearly stated, "for my purposes". Could be "count average block time which isn't provided by blockchain.info"  

---

