Bitcoin Core pruned blockchain: download it here! (DON'T DO THIS!)

[LoyceV]

First: It's NOT recommended to download the blockchain any other way than having Bitcoin Core download it on it's own. Don't do it! Seriously, don't!

Still reading? Well, you'd better know what you're doing, you're on your own now

Download a pruned blockchain
I've seen several topics about downloading and pruning Bitcoin Core. It can take a long time, and you'll need to download about 220 450 GB before it's done. After pruning, you'll only have a few 5 GB left.
Since I was playing around with a VPS anyway, I now create daily snapshots of the "blocks" and "chainstate" directories. Download the latest pruned Bitcoin blockchain, unpack it to the right directory, and start your own Bitcoin Core (I'm using v0.18.0.0, older than this may not work). Configure it to prune the blockchain and you're good to go.
It should connect, and update the blocks from there. Once running, you won't need to update it from my server anymore.
This should make it possible to get a pruned and up-to-date Bitcoin Core running in an hour instead of a couple of days (or weeks on some systems).

Which directory to use (source: stackexchange.com)

Linux:

Code:

~/.bitcoin/

MacOS:

Code:

~/Library/Application Support/Bitcoin/

Windows:

Code:

%APPDATA%\Bitcoin

While my VPS is still syncing, I'd like to start some discussion about this:
How risky is this?
You have to trust not only me, but also my VPS and shared hosting too, and I can't make any guarantees about the last 2. If someone downloads my 550 blocks and his own Bitcoin Core connects and downloads the most recent blocks from there, is that enough to be fairly certain it's on the real chain?

On Reddit, theymos wrote this 3 years ago:

This is massively insecure. Bitcoin Core trusts its block database files absolutely. /u/nullc has said that it is not particularly unlikely that a maliciously-modified block database could be used for arbitrary code execution. And even if that's not possible, all sorts of more obvious evil could be done, such as allowing the provider of the block database to create a special killswitch transaction which forks everyone who used his block database, or having everyone who used his block database think that he actually owns 22 million BTC.

Nobody should ever receive block database files from untrusted sources.

Also see: https://en.bitcoin.it/wiki/Data_directory#Transferability

So again: don't do it!

[1715383557]

1715383557

[1715383557]

1715383557

[1715383557]

1715383557

[1715383557]

1715383557

[1715383557]

1715383557

[Carlton Banks]

yep, don't do this

[aliashraf]

op,
Obviously getting rid of the headache of bitcoin bootstrap is a very important topic but surprisingly it is an old story ...

@eurekafag AFAIK is the first person who said something about it, july 2010(!), he used the term snapshotting (it is why I used it above, to show my respect). The topic got no attention but another user, @Bytecoin rephrased it two days later and posted a more comprehensive proposal.

Satoshi Nakamoto was still around and he never made a comment regarding this, Gavin Andersen didn't get it, neither @Theymos, ... just 2 and a half pages of non-productive discussions. Obviously in mid 2010 there were few blocks, few UTXOs and so many other problems and priorities.

Almost one year later, july 2011, Gregory Maxwell, made a contribution to this subject he basically proposed something that later was termed, UTXO Commitment, it was Merkle era, people were excited about the magical power of Merkle Trees and Maxwell proposed maintaining a Merkle Hash Tree of UTXO by full nodes that enables them to spot an unspent output efficiently while miners include the root of such a tree in coinbase transaction (later others proposed including it directly in block header) this way, 'lite clients' would be able to ask for proof of any tx input as being committed to the UTXO Merkle root included in latest blocks.  

Months ago, when I was writing the above paragraphs, I was somehow confused supposing it would need a hard fork to be implemented which is not true.
Actually, it is very easy to have such a UTXO commitment feature in bitcoin with a very small piece of code and a soft-fork as legacy nodes could continue confirming blocks and won't fork out.

I've contributed to this subject even more and proposed an even softer approach for implementing this idea. According to my approach, we don't need to enforce an upgrade for a majority of full nodes. We need a majority of good UTXO actors against the malicious ones:

Suppose we have convinced like 10% of miners to join our UTXO commitment upgrade such that we have like 50 good UTXO signals every 100 blocks, now it will be enough to have less than 10 bad UTXO signals in the same window of time (i.e. 440 null signals). Upgraded nodes could consider forking from blocks with malicious signals after they get a majority of like 450 consistent signals in last 500 blocks.

UTXO commitment has been discussed and developed a lot more after G Maxwell has proposed and abandoned it, but what bothers me is how it has been undermined in bitcoin community and boosted in BCH. They have done a lot more about it in bitcoin cash and I'm just like  

[Carlton Banks]

UTXO commitment has been discussed and developed a lot more after G Maxwell has proposed and abandoned it, but what bothers me is how it has been undermined in bitcoin community

you clearly aren't familiar with the parable of the hare and the tortoise

• hare and tortoise race
• hare begins race too fast
• hare takes nap, overconfident of win
• tortoise wins while hare asleep

please don't reply, you have a bad reputation

[aliashraf]

UTXO commitment has been discussed and developed a lot more after G Maxwell has proposed and abandoned it, but what bothers me is how it has been undermined in bitcoin community

you clearly aren't familiar with the parable of the hare and the tortoise

• hare and tortoise race
• hare begins race too fast
• hare takes nap, overconfident of win
• tortoise wins while hare asleep

please don't reply, you have a bad reputation

Joking? Tortoises lose nowadays, wake-up and don't say anything more, besides your worse reputation, you are trolling right now.

[tbct_mt2]

Yes, don't do this!

Around less than one year ago, when I searched for bitcoin wallets (that is my first time to use bitcoin wallets that I can control private key). I firstly began with bitcoin core wallet, and as OP wrote, my computer was unable to fully synchronize with bitcoin network, due to hardware storage capacity.
It was also slow down my computer operating speed, so I gave up, and search more.
Finally, I found good threads on Electrum (in forum), and used Electrum by now.

[aplistir]

Brilliant idea 

You do not need to have daily snapshots of it though. Even 6 months old snapshot would speed up the sync considerably.

Would be even better if you could make a pruned and zipped blockchain available, get a hash of it, and some other users verify that the pruned blockchain is correct. (how?)
Then new downloaders can trust with even higher certainty that it has not been tampered with.

[aliashraf]

I'd rather run SPV client and connect to lots of full nodes rather than do this

UTXO commitment has been discussed and developed a lot more after G Maxwell has proposed and abandoned it, but what bothers me is how it has been undermined in bitcoin community and boosted in BCH. They have done a lot more about it in bitcoin cash and I'm just like  

It's not undermined, but generally people aren't interested to use UTXO commitment because actual full node (which validate and store all blocks) is still needed and higher degree of trust required.

I've been debating this __higher degree of trust__ thing at least two times with Andrew and Greg and found no reason behind their arguments. If they haven't moved this thread from technical sub-forum I'd include a full mathematical analysis right here to prove there is no trust issue (I mean a practical issue). Briefly speaking, there is no rational attack scenario for generating a large number of blocks committing to a poisoned UTXO. To be more specific there is always a number n for the pruned chain length that guarantees full security from a game-theoretic point of view. For current bitcoin blockchain, a UTXO with 2000 block commitments is practically safe for wallets that are handling 1 billion dollars worth of assets! The only possible problem would be Sybill attack which could be easily mitigated by introducing a lower bound for difficulty when bootstrapping or including checkpoints. It can also be included in the protocol itself: require more "work" instead of more number of commitments. easy.

As of your comment about the need for full nodes, let's make it crystal clear: A pruned node IS actually a full node! The only shortage they have is their inability to help with the current sync strategy in bitcoin which is absurd anyway.

On a different note, have you heard about Neutrino? It's quite interesting protocol for SPV/light wallet which offer some degree of privacy.

Yes, I know about client-side filtering. It helps with privacy for spv wallets. Alternatively, I'm thinking of eliminating spv wallets completely.

[pooya87]

this topic may not be appropriate in the beginners and help board. the warning part is OK but the walk-through followup doesn't belong here. it is best be posted in project development board since the only usage i can think of for this is mostly for developers trying to test things and don't need trust or security.

[ABCbits]

I've been debating this __higher degree of trust__ thing at least two times with Andrew and Greg and found no reason behind their arguments. If they haven't moved this thread from technical sub-forum I'd include a full mathematical analysis right here to prove there is no trust issue (I mean a practical issue). Briefly speaking, there is no rational attack scenario for generating a large number of blocks committing to a poisoned UTXO. To be more specific there is always a number n for the pruned chain length that guarantees full security from a game-theoretic point of view. For current bitcoin blockchain, a UTXO with 2000 block commitments is practically safe for wallets that are handling 1 billion dollars worth of assets! The only possible problem would be Sybill attack which could be easily mitigated by introducing a lower bound for difficulty when bootstrapping or including checkpoints. It can also be included in the protocol itself: require more "work" instead of more number of commitments. easy.

I should specify the higher degree of trust depends on how they implement UTXO commitment. Few implementation (sometimes under different name) i've seen are ridiculous, such have central or master node as UTXO source.

The UTXO commitment idea itself isn't bad and i don't mind if Bitcoin protocol/client adopt UTXO commitment feature (if done right).
But personally, i prefer use it to allow client to use their Bitcoin while waiting all blocks are downloaded & verified.

[aliashraf]

The UTXO commitment idea itself isn't bad and i don't mind if Bitcoin protocol/client adopt UTXO commitment feature (if done right).
But personally, i prefer use it to allow client to use their Bitcoin while waiting all blocks are downloaded & verified.

Koodos  
Very good strategy, I can imagine a lazy synchronization process for extending the chain height in reverse order as far as the user wishes and she is capable of affording resources for this.

this topic may not be appropriate in the beginners and help board. the warning part is OK but the walk-through followup doesn't belong here. it is best be posted in project development board since the only usage i can think of for this is mostly for developers trying to test things and don't need trust or security.

Actually, it was opened in the right board, mods moved it here apparently because of the "Don't do this!" thing.

[LoyceV]

You do not need to have daily snapshots of it though. Even 6 months old snapshot would speed up the sync considerably.

Making one zip-file per day is not a problem. I've already set it up in a cronjob.

Would be even better if you could make a pruned and zipped blockchain available, get a hash of it, and some other users verify that the pruned blockchain is correct. (how?)

I tried that before, but the files on disk (such as "blk01117.dat") are different on other systems. It would have been easy to create a checksum if those files would be exact copies all the time.

this topic may not be appropriate in the beginners and help board. the warning part is OK but the walk-through followup doesn't belong here. it is best be posted in project development board since the only usage i can think of for this is mostly for developers trying to test things and don't need trust or security.

Good point, for developers it could be convenient to quickly have a pruned node running. Although some would argue that's what the Testnet is for.
I posted this in Project Development, but a Mod seemed to disagree.

Actually, it was opened in the right board, mods moved it here apparently because of the "Don't do this!" thing.

I wanted to make very clear this isn't supposed to be used for real funds, but I also believe in freedom to make your own choices.

[LoyceV]

I last updated this project 3 years ago, so I just deleted the files.

The subject of downloading a pruned blockchain came up in a few recent posts:
Is anyone working in a "pruned download"?

I don't know how BTCapsule works with this, but last time I checked pruned node for Bitcoin was around 5.1 Gb in size, that is significantly less than full blockchain that is around 86 times bigger.
https://prunednode.today/

Note that I don't know who's behind this website.

I stopped updates when the VPS it was on disappeared, but I've got hosting covered now so I could start it up again. If there's any demand for my "DON'T DO THIS"-service, let me know.

[dkbit98]

Note that I don't know who's behind this website.

Main person behind this project is Stepan Snigirev and all project is maintained by Specter wallet team.
They are working on open source Specter DIY hardware wallet signing device, Specter desktop wallet, Lightning network, and everything related with Bitcoin.
If you want you can contact him on his email and social media to confirm this information, so you don't have to trust my words

[Greg Tonoski]

There is also the 2024-02-26 18:27:40 UTC snapshot (approx. 11 GB, pruned) available for download from Google Drive: https://drive.google.com/drive/folders/1xGNGngrcyOh4UZbXzpqx0fTZImioFLpc (or the shorter URL: https://spoo.me/51pVZm).

[ascqrwasc33]

There is also the 2024-02-26 18:27:40 UTC snapshot (approx. 11 GB, pruned) available for download from Google Drive: https://drive.google.com/drive/folders/1xGNGngrcyOh4UZbXzpqx0fTZImioFLpc (or the shorter URL: https://spoo.me/51pVZm).

What was the the prune= set to when you pruned it?

[LoyceV]

What was the the prune= set to when you pruned it?

Probably the minimum (550). But it doesn't matter: once you have a pruned node, you can change this number (which will only affect new blocks).

[ascqrwasc33]

What was the the prune= set to when you pruned it?

Probably the minimum (550). But it doesn't matter: once you have a pruned node, you can change this number (which will only affect new blocks).

I might have kept it larger than what the files were pruned at so maybe that's why  I was getting an inconsistency error.
BTW LoyceV,  I am using Greg Tonoski's link since yours is empty