sweet mother of god, the blockchain is HUGE

[jojo69]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

[1715655768]

1715655768

[1715655768]

1715655768

[bluemeanie1]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

now imagine that the number of transactions are multiplied by number of CoinColors or Mastercoins, etc?

it's just simply impossible to host these extra transactions on top of normative bitcoin.

[antonin]

http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/
You can get it from there. Hope you enjoy it.

[jojo69]

is that quicker antonin?  how do you graft that download on to QT?

[Come-from-Beyond]

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

U may face an interesting effect - https://bitcointalk.org/index.php?topic=294627.msg3158832#msg3158832.

[forbun]

Yes, it's MUCH faster. Put bootstrap.dat in your bitcoin-qt data directory.

[knightmb]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

Trying wiping the entire block chain and starting over from null. There are not really enough active nodes to download the entire chain in less than a week on even the fastest connection because the rates from the nodes is so low. 

[trout]

according to the devs, the "default" client is no longer bitcoin-qt but Multibit

It takes less than a minute to be fully connected after downloading the client (it's an SPV client,
it doesn't download the blockchain). It'd be somewhat longer if you have to import
old private keys (the older they are, the longer it takes to synchronise) but it's still incomparable to downloading
the whole blockchain.

[bezzeb]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

Hey, you can read up a bit on potential improvements in the milestone .9 release which is in the pipe:
https://bitcoinfoundation.org/blog/?p=290

I mention it because it has some very interesting stuff related to this problem.  Of note:  Headers first downloading, and Provably prunable outputs.  I'll pause while every reads and absorbs the wisdom.    ... ... ...

Of note for your question: 
Headers first is a breakthrough that will allow true bit-torrent style parallel downloading of the blockchain.  The reason it's quite slow now is that it must be downloaded in serial sequence from block 0 to now.  Headers only means you can essentially just grab all the block headers to build a "table of contents" so to speak for the whole chain.  Then AFTER this, you can fetch the transaction details of each block to fill in all the gaps in a massively parallel way.

Proveably Prunable outputs is a new way to help mitigate future size explosion in the block chain by allowing a legitimate way for messages to be inserted into the blockchain - and most importantly to let nodes ignore these messages if they don't want to archive them.  It creates the potential to have "archival" nodes on heavy duty servers that store everything for everyone, and then "normal" nodes which just store transactions.  Currently we all store everything which is not sustainable for average users as you have discovered.

Not mentioned but coming hopefully before release 1.0:  methods to remove spent transactions from the blockchain to start to prune the size down and hopefully level off at some plateau size that is more stable and less exponential.  There have been many proposals on how to do this, but i suspect it would involve the spin off of another "type" of bitcoin node which is intended for desktop computer use which has a version of the blockchain that has fully spent transactions summarized by some cryptographic method like merkle trees and then removed to save space.  This is a really gnarly / ugly problem though so i think it's been lowered in priority compared to all the other key useability features they are working on.

As for mass adoption:  the future will not look like today.   Pulling out my crystal ball, i see:  Full heavy weight nodes will shift into serious players hands - ie: serious investors, financial institutions and hard core hobbyists.  "Light chain" clients with compressed or summarized block chains will fill some middle ground.  Light weight clients with no local block chain (like Multibit) will fill another niche.  And then for the unrully mobs and unwashed masses - they will use banks with possibly bitcoin backends (using full heavy nodes).

Why?  The idea of having the responsibility to keep wallets safe and not letting them get stolen for example by malware is a responsibility which most average folks do not want to have.  They will prefer some protection from a bank-like institution to help keep their money safe for some modest fee - kind of like online wallets - or the idealized version of the current banking system from old hollywood films.

[zvs]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

Trying wiping the entire block chain and starting over from null. There are not really enough active nodes to download the entire chain in less than a week on even the fastest connection because the rates from the nodes is so low.  

set maxconns to 1

then connect=5.9.24.81  (and change it back after it's finished)

i have plenty of bandwidth unless some DoS is going on

[jojo69]

That, bezzeb, was certainly a better executive summary than I expected or deserved.

Thank you for taking the time sir.


As to the other comment of multibit being the "default" client.  I tried installing that and got a popup that it required java...well, that swiss cheese pile of excrement is not going on my box period.  How is it that the "default" client requires a known insecure browser extension?

[kjj]

set maxconns to 1

then connect=5.9.24.81  (and change it back after it's finished)

i have plenty of bandwidth unless some DoS is going on

Hopefully that box is serving the chain from a RAM disk.  Bootstrapping a new node from a spinning disk causes a TON of thrashing.  SSDs are decent, but DRAM is king.

[forbun]

Java isn't a browser extension. There is a Java runtime that can be used a browser plug-in, but I don't think this is the same Java required by Multibit.

[mb300sd]

set maxconns to 1

then connect=5.9.24.81  (and change it back after it's finished)

i have plenty of bandwidth unless some DoS is going on

Hopefully that box is serving the chain from a RAM disk.  Bootstrapping a new node from a spinning disk causes a TON of thrashing.  SSDs are decent, but DRAM is king.

YES, making a temporary ramdisk and using -datadir makes it sync much faster. This might not be an option for everyone, but for anyone using bitcoind on a heavy duty server, its a no-brainer.

[DeathAndTaxes]

YES, making a temporary ramdisk and using -datadir makes it sync much faster. This might not be an option for everyone, but for anyone using bitcoind on a heavy duty server, its a no-brainer.

This.  I skipped the temporary part and just left the blockchain on ramdisk with backup to fixed disks.   The good news is memory is cheap, insanely cheap these days.  If you are looking at doing any serious bitcoin backend work $100 or $200 on memory increase is worth far more than upgrading any other component.

[Come-from-Beyond]

memory increase is worth far more than upgrading any other component.

Desktop with 8 GiB and 1 Mb/s spent 2+ weeks to download blockchain.
Virtual machine with 256 (or 512, not sure) MiB and 100 Mb/s spent 1.5 days for the same.

RAM is not the silver bullet.

[mb300sd]

memory increase is worth far more than upgrading any other component.

Desktop with 8 GiB and 1 Mb/s spent 2+ weeks to download blockchain.
Virtual machine with 256 (or 512, not sure) MiB and 100 Mb/s spent 1.5 days for the same.

RAM is not the silver bullet.

RAMdisk, not only RAM. The biggest bottleneck is disk access, when disk == ram, that goes away.

[kjj]

memory increase is worth far more than upgrading any other component.

Desktop with 8 GiB and 1 Mb/s spent 2+ weeks to download blockchain.
Virtual machine with 256 (or 512, not sure) MiB and 100 Mb/s spent 1.5 days for the same.

RAM is not the silver bullet.

RAMdisk, not only RAM. The biggest bottleneck is disk access, when disk == ram, that goes away.

Indeed.  And, as I think I mentioned before, the biggest download speed enhancement is having a RAMdisk on the sending side.  Writing the block file out sequentially isn't hard for spinning disks to do.  Seeking backwards through it one un-aligned jump at a time is murder.

RAMdisk -> magnetic drive isn't much slower than RAMdisk -> RAMdisk, but it beats the crap out of magnetic drive -> anything.

[Sukrim]

Hmmm... memcached blockchain implementation for bitcoind anyone?

[BadAss.Sx]

new OS on a new box here, been...oh I don't know...year and a half since I have to set bitcoin QT up from scratch

sweet baby zombie jesus, hours and hours, I got hours to go, still 15 weeks back and the weeks are obviously getting bigger all the time

obviously this has to be a tired topic so forgive me, what are the strategies that have been proposed to deal with this?  Couple years ago it was inconvenient, now it is ridiculous, couple years from now it will be untenable.

mass adoption indeed, lol

Mine was done after 7 days and 6 hours while a few months back it took 1.5 days.