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

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

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

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

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

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

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"?
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.

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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

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

op,
Obviously getting rid of the headache of bitcoin bootstrap is a very important topic but surprisingly it is an old story ...
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  

yep, don't do this

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)

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:
So again: don't do it!