Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: nebulus on September 14, 2012, 06:10:42 PM



Title: Size of BTC blockchain centuries from now...
Post by: nebulus on September 14, 2012, 06:10:42 PM
Hello, I am sitting here and downloading the transaction history in order to test the wallet I had backed up months ago. Let me tell you, it's been two days already and a major pain in the ass. But anyway, this got me thinking if we approach the future where BTC transaction are going to increase (exponetionally or not) does the blockchain size eventually become infinite? Also, how in the world people who can't afford equipment that can process large data, would benefit from BTC?

Thanks for answers!


Title: Re: Size of BTC blockchain centuries from now...
Post by: DeathAndTaxes on September 14, 2012, 06:17:51 PM
In 1980 a 26 MB hard drive cost ~$5,000 (or $193,000,000 per TB).
Obviously angry birds isn't viable.  I mean who is going to spend a couple hundred dollars in storage on a free game. :)


Title: Re: Size of BTC blockchain centuries from now...
Post by: flatfly on September 14, 2012, 06:29:56 PM
Other clients than Bitcoin-Qt are available, not all of which require the full blockchain: dre.redmartian.org/compare.htm


Title: Re: Size of BTC blockchain centuries from now...
Post by: nebulus on September 14, 2012, 06:33:54 PM
In 1980 a 26 MB hard drive cost ~$5,000 (or $193,000,000 per TB).
Obviously angry birds isn't viable.  I mean who is going to spend a couple hundred dollars in storage on a free game. :)

Well, you are assuming here that storage space/bandwidth will increase at the same rate as the number of transactions. I guess there is an equilibrium point somewhere here. Bitcoin just have to wait until better tech comes around. So technically, if there is no better tech, Bitcoins fucked.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Gavin Andresen on September 14, 2012, 06:35:59 PM
Right now, there is a hard-coded limit of 1 megabyte per block.

If we assume that limit never changes, that gives:
 1MB per block * 6 blocks per hour * 24*365.25*200 = 10,519,200 MB

... or 10.5 terabytes for the maximum size of the entire blockchain over the next 200 years (somebody check my math, I'm really good at dropping zeroes).

I expect that in 200 years 10 terabytes of storage will cost a few pennies.


Now whether or not that 1 megabyte per block limit should go away is hotly debated, and will be debated more and more as transaction volume increases.


Title: Re: Size of BTC blockchain centuries from now...
Post by: nebulus on September 14, 2012, 06:41:26 PM
I expect that in 200 years 10 terabytes of storage will cost a few pennies.

Okay, I should have been more accurate in forming my thought.
Besides, just storage... there is bandwidth, HD (device speed), probably RAM is somehow also intertwined to search the transaction history, etc...



Title: Re: Size of BTC blockchain centuries from now...
Post by: SgtSpike on September 14, 2012, 06:50:15 PM
I expect that in 200 years 10 terabytes of storage will cost a few pennies.

Okay, I should have been more accurate in forming my thought.
Besides, just storage... there is bandwidth, HD (device speed), probably RAM is somehow also intertwined to search the transaction history, etc...


Then there's the option of a lite client that doesn't require downloading the blockchain.


Title: Re: Size of BTC blockchain centuries from now...
Post by: DeathAndTaxes on September 14, 2012, 07:13:11 PM
I expect that in 200 years 10 terabytes of storage will cost a few pennies.

Okay, I should have been more accurate in forming my thought.
Besides, just storage... there is bandwidth, HD (device speed), probably RAM is somehow also intertwined to search the transaction history, etc...

All of which have been doubling in terms of x/$ for decades now.  While they don't all follow Moore's law exactly they are all exponential.  It is inconceivable that 50 years from now RAM, storage, computing power, and internet connectivity bandwidth won't be many magnitudes higher than today both in absolute terms and in performance per dollar.

Still as SgtSpike pointed out there are lite-nodes which don't require the complete blockchain.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Ascholten on September 16, 2012, 12:07:00 PM
30 years ago we had 1 mhz 8 bit processors,   maybe a whole whopping 128k of ram, 140k fancy new 5 inch floppy disks and you might have been one of the rich guys who could afford the fancy new 1200 baud accoustical modem instead of the 300 baud normally used to hook up to your favority BBS.  Hard drives were there, I think 40 meg was the high end for consumer at a price tag of about 1200 bucks if I remember properly.

Look at what we have today.

16 core, multi gigahertz processors,  128 Gigs of ram, solid state drives or you can grab a 3 terabyte HDD fairly cheap, and baud rates in the mega and giga range.  Let's not forget the 'free' internet access at many many coffee shops, mcdonalds, etc as you travel around, and libraries too.

Somehow I have a feeling that as the size of the chains grow, so will technology so it should not be an issue really.

Aaron


Title: Re: Size of BTC blockchain centuries from now...
Post by: Realpra on September 16, 2012, 12:33:50 PM
Swarm client combined with 10-year-ledger, search the forum and rejoice ;)


Title: Re: Size of BTC blockchain centuries from now...
Post by: nebulus on September 18, 2012, 01:57:35 PM
Swarm client combined with 10-year-ledger, search the forum and rejoice ;)

+1


Title: Re: Size of BTC blockchain centuries from now...
Post by: AbsoluteZero on September 25, 2012, 05:48:14 AM
Right now, there is a hard-coded limit of 1 megabyte per block.


Is the 1 megabyte hard-coded limit something expected to change?

If it stays like that, I guess Bitcoin will not be good for micro payments as transaction fees will rise.

If the limit is raised, the blockchain will grow faster than expected.

Whatever is done has pros and cons

What direction is Bitcoin going to take? Who decides?

 ???



Title: Re: Size of BTC blockchain centuries from now...
Post by: mem on September 25, 2012, 07:20:34 AM
Right now, there is a hard-coded limit of 1 megabyte per block.

If we assume that limit never changes, that gives:
 1MB per block * 6 blocks per hour * 24*365.25*200 = 10,519,200 MB

... or 10.5 terabytes for the maximum size of the entire blockchain over the next 200 years (somebody check my math, I'm really good at dropping zeroes).

I expect that in 200 years 10 terabytes of storage will cost a few pennies.


Now whether or not that 1 megabyte per block limit should go away is hotly debated, and will be debated more and more as transaction volume increases.

Nice info, thanks Gavin  :)


Title: Re: Size of BTC blockchain centuries from now...
Post by: Mike Hearn on September 25, 2012, 12:39:46 PM
I think the limit will go away and also that it won't matter.

Storage is really cheap guys. If you end up needing an array of terabyte drives to hold the whole chain, so what? Most nodes and virtually all participants in the system won't need the entire dataset.

Bear in mind not one but several organizations store the entire web and the history of almost every page, on hard disks.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Gabi on September 25, 2012, 01:45:18 PM
Please note that the long time it takes to download the blockchain is not a download limit. It's because for each block the client check the blockchain to be sure it's ok and yaddayadda. So basically it's epic hard disk crunching.
Just downloading the blockchain would take less than a hour now, it's not even 4GB. It's the verify part that slow down it.


Title: Money is the power
Post by: Yurock on September 25, 2012, 02:09:31 PM
Block chain size growth will make installation of new full nodes expensive. Number of full nodes may decrease with time. In that case, power over Bitcoin network will likely move to few rich enough entities. Lightweight clients rely on full nodes.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Mike Hearn on September 25, 2012, 02:34:02 PM
You can run a full node that prunes (see Satoshis paper). The only time when you need nodes that have full block chain copies is to bootstrap new nodes from scratch, which will eventually be quite rare - but that doesn't imply there are only a few nodes, just that setting one up isn't something lots of people do every day.

Also, nothing stops you acquiring a copy of the database that you know is trustable (eg, there is a hash of it in the git repository) and bootstrapping from that, you don't have to rebuild the entire DB from scratch.


Title: Re: Size of BTC blockchain centuries from now...
Post by: AbsoluteZero on September 25, 2012, 03:03:06 PM
I think the limit will go away and also that it won't matter.

Storage is really cheap guys. If you end up needing an array of terabyte drives to hold the whole chain, so what? Most nodes and virtually all participants in the system won't need the entire dataset.

Bear in mind not one but several organizations store the entire web and the history of almost every page, on hard disks.

The limit will not just ”go away”

Most of the network has to agree




Title: Supposed future deficiency in new installations
Post by: Yurock on September 25, 2012, 08:31:08 PM
You can run a full node that prunes
Which will save, say, 70% of space. One will still have to obtain a copy of remaining 30% at least, which will be a lot, still.

I am concerned about supposed future deficiency in new installations. Most existing installations will be shut down sooner or later for various reasons. Without enough new installations, number of full nodes can drop low enough for one powerful entity to be able to control most of the remaining.

that doesn't imply there are only a few nodes
In my opinion, few will be interested in hosting huge amount of data.

Also, nothing stops you acquiring a copy of the database that you know is trustable (eg, there is a hash of it in the git repository) and bootstrapping from that
Yes, I am talking about bootstrapping from trusted data. I'm not sure if full verification of the block chain will be feasible at all.


Title: Re: Size of BTC blockchain centuries from now...
Post by: dreamwatcher on September 25, 2012, 09:02:58 PM
Please note that the long time it takes to download the blockchain is not a download limit. It's because for each block the client check the blockchain to be sure it's ok and yaddayadda. So basically it's epic hard disk crunching.
Just downloading the blockchain would take less than a hour now, it's not even 4GB. It's the verify part that slow down it.

Has anybody attempted/published a client or utility that could could verify the chain using openCL?

GPUS are used for the hashing involved mining now, is there a reason why it would be inefficient to verify the same way?

Maybe another project to put on my list? However, I would think that professional developers much more advanced in this technology have already considered it.  ;D



Title: Speeding up block verification
Post by: Yurock on September 25, 2012, 09:13:28 PM
Has anybody attempted/published a client or utility that could could verify the chain using openCL?

GPUS are used for the hashing involved mining now, is there a reason why it would be inefficient to verify the same way?
In my experience, the bottleneck is not in computation. The slowest thing during block verification are database operations. Within one block, different transaction "inputs" use "outputs" from different previous blocks. The program needs to access all of those blocks to verify "inputs".


Title: Re: Size of BTC blockchain centuries from now...
Post by: Desolator on September 28, 2012, 04:58:34 AM
Btw, how big is the database right now?  It's not stored in the directory I thought it was but I assume my updated but original client contains the entire chain db.  Speaking of that, what directly is it stored in for Windows 7 64-bit?  Because it uses soooooooooo much IO, I want to move it to a secondary drive if possible.

Also, I know this has massive security concerns but if someone downloaded a client that included a giant 1 year history worth of the block chain database for example, how compressed archive friendly would the database file(s) be?


Title: Re: Size of BTC blockchain centuries from now...
Post by: Dabs on September 28, 2012, 02:05:49 PM
Centuries from now, the block chain might be a few terabytes in size. But every smart phone in the whole world can store it on the latest version of the microsd card, or even in the phone memory.

Our bandwidth speeds would allow a new phone to completely download the block chain in 1 hour from the neighborhood coffee shop that has free LTE (or whatever WIFI there is then.)

The lite clients wouldn't exist because every person with the slowest and oldest working smart phone runs a full node, and the higher end phones would be mining. The desktops at homes would be mining too in the high ultra-tera-bazillion-hash rates, for the 0.000001 BTC we get for every block every 10 minutes at an obscenely high trillion difficulty.

Then, centuries later, someone inherits an envelope that has a paper wallet with 10 bitcoin private keys, each one worth a few thousand full bitcoins (whereas everyone else has about a dozen bitcoins total worth their annual salary) that was saved a few decades prior.


Title: Re: Size of BTC blockchain centuries from now...
Post by: kjj on September 28, 2012, 03:45:49 PM
Btw, how big is the database right now?  It's not stored in the directory I thought it was but I assume my updated but original client contains the entire chain db.  Speaking of that, what directly is it stored in for Windows 7 64-bit?  Because it uses soooooooooo much IO, I want to move it to a secondary drive if possible.

Also, I know this has massive security concerns but if someone downloaded a client that included a giant 1 year history worth of the block chain database for example, how compressed archive friendly would the database file(s) be?

Code:
2012-02-19 1028273116 /etc/bitcoin/blk0001.dat
2012-02-20 1030893023 /etc/bitcoin/blk0001.dat
2012-02-21 1033600078 /etc/bitcoin/blk0001.dat
2012-02-22 1036884969 /etc/bitcoin/blk0001.dat
2012-02-23 1040070244 /etc/bitcoin/blk0001.dat
2012-02-24 1043757836 /etc/bitcoin/blk0001.dat
2012-02-25 1047055454 /etc/bitcoin/blk0001.dat
2012-02-26 1049849268 /etc/bitcoin/blk0001.dat
2012-02-27 1052491609 /etc/bitcoin/blk0001.dat
2012-02-28 1055614369 /etc/bitcoin/blk0001.dat
2012-02-29 1058808039 /etc/bitcoin/blk0001.dat
2012-03-01 1061836655 /etc/bitcoin/blk0001.dat
2012-03-02 1065729757 /etc/bitcoin/blk0001.dat
2012-03-03 1068703901 /etc/bitcoin/blk0001.dat
2012-03-04 1071294341 /etc/bitcoin/blk0001.dat
2012-03-05 1074387846 /etc/bitcoin/blk0001.dat
2012-03-06 1077978733 /etc/bitcoin/blk0001.dat
2012-03-07 1081143206 /etc/bitcoin/blk0001.dat
2012-03-08 1084187734 /etc/bitcoin/blk0001.dat
2012-03-09 1087216165 /etc/bitcoin/blk0001.dat
2012-03-10 1090632277 /etc/bitcoin/blk0001.dat
2012-03-11 1093027825 /etc/bitcoin/blk0001.dat
2012-03-12 1095717413 /etc/bitcoin/blk0001.dat
2012-03-13 1098872551 /etc/bitcoin/blk0001.dat
2012-03-14 1102999881 /etc/bitcoin/blk0001.dat
2012-03-15 1106390198 /etc/bitcoin/blk0001.dat
2012-03-16 1109340729 /etc/bitcoin/blk0001.dat
2012-03-17 1112547621 /etc/bitcoin/blk0001.dat
2012-03-18 1115430766 /etc/bitcoin/blk0001.dat
2012-03-19 1118175379 /etc/bitcoin/blk0001.dat
2012-03-20 1121299358 /etc/bitcoin/blk0001.dat
2012-03-21 1124459929 /etc/bitcoin/blk0001.dat
2012-03-22 1127385378 /etc/bitcoin/blk0001.dat
2012-03-23 1130211449 /etc/bitcoin/blk0001.dat
2012-03-24 1133069304 /etc/bitcoin/blk0001.dat
2012-03-25 1135859931 /etc/bitcoin/blk0001.dat
2012-03-26 1138999144 /etc/bitcoin/blk0001.dat
2012-03-27 1141954800 /etc/bitcoin/blk0001.dat
2012-03-28 1145074237 /etc/bitcoin/blk0001.dat
2012-03-29 1148504098 /etc/bitcoin/blk0001.dat
2012-03-30 1151818132 /etc/bitcoin/blk0001.dat
2012-03-31 1154944079 /etc/bitcoin/blk0001.dat
2012-04-01 1157573274 /etc/bitcoin/blk0001.dat
2012-04-02 1160508007 /etc/bitcoin/blk0001.dat
2012-04-03 1164407015 /etc/bitcoin/blk0001.dat
2012-04-04 1168059554 /etc/bitcoin/blk0001.dat
2012-04-05 1171859799 /etc/bitcoin/blk0001.dat
2012-04-06 1175214760 /etc/bitcoin/blk0001.dat
2012-04-07 1178503398 /etc/bitcoin/blk0001.dat
2012-04-08 1181164181 /etc/bitcoin/blk0001.dat
2012-04-09 1183853502 /etc/bitcoin/blk0001.dat
2012-04-10 1187162797 /etc/bitcoin/blk0001.dat
2012-04-11 1191063672 /etc/bitcoin/blk0001.dat
2012-04-12 1195003097 /etc/bitcoin/blk0001.dat
2012-04-13 1198613547 /etc/bitcoin/blk0001.dat
2012-04-14 1201986837 /etc/bitcoin/blk0001.dat
2012-04-15 1205257888 /etc/bitcoin/blk0001.dat
2012-04-16 1208864649 /etc/bitcoin/blk0001.dat
2012-04-17 1213032914 /etc/bitcoin/blk0001.dat
2012-04-18 1217397654 /etc/bitcoin/blk0001.dat
2012-04-19 1221412762 /etc/bitcoin/blk0001.dat
2012-04-20 1225158640 /etc/bitcoin/blk0001.dat
2012-04-21 1229536626 /etc/bitcoin/blk0001.dat
2012-04-22 1232508822 /etc/bitcoin/blk0001.dat
2012-04-23 1235743036 /etc/bitcoin/blk0001.dat
2012-04-24 1239154645 /etc/bitcoin/blk0001.dat
2012-04-25 1242809309 /etc/bitcoin/blk0001.dat
2012-04-26 1247061559 /etc/bitcoin/blk0001.dat
2012-04-27 1250610923 /etc/bitcoin/blk0001.dat
2012-04-28 1253971213 /etc/bitcoin/blk0001.dat
2012-04-29 1257188789 /etc/bitcoin/blk0001.dat
2012-04-30 1260866573 /etc/bitcoin/blk0001.dat
2012-05-01 1265190100 /etc/bitcoin/blk0001.dat
2012-05-02 1270163555 /etc/bitcoin/blk0001.dat
2012-05-03 1275254112 /etc/bitcoin/blk0001.dat
2012-05-04 1282006483 /etc/bitcoin/blk0001.dat
2012-05-05 1287707753 /etc/bitcoin/blk0001.dat
2012-05-06 1294218855 /etc/bitcoin/blk0001.dat
2012-05-07 1300269417 /etc/bitcoin/blk0001.dat
2012-05-08 1308494966 /etc/bitcoin/blk0001.dat
2012-05-09 1316495890 /etc/bitcoin/blk0001.dat
2012-05-10 1323694667 /etc/bitcoin/blk0001.dat
2012-05-11 1330328973 /etc/bitcoin/blk0001.dat
2012-05-12 1339111094 /etc/bitcoin/blk0001.dat
2012-05-13 1346342075 /etc/bitcoin/blk0001.dat
2012-05-14 1355724696 /etc/bitcoin/blk0001.dat
2012-05-15 1366893298 /etc/bitcoin/blk0001.dat
2012-05-16 1377294005 /etc/bitcoin/blk0001.dat
2012-05-17 1384497000 /etc/bitcoin/blk0001.dat
2012-05-18 1393788808 /etc/bitcoin/blk0001.dat
2012-05-19 1409455981 /etc/bitcoin/blk0001.dat
2012-05-20 1425077523 /etc/bitcoin/blk0001.dat
2012-05-21 1438993690 /etc/bitcoin/blk0001.dat
2012-05-22 1450841819 /etc/bitcoin/blk0001.dat
2012-05-23 1462765298 /etc/bitcoin/blk0001.dat
2012-05-24 1473824462 /etc/bitcoin/blk0001.dat
2012-05-25 1487811671 /etc/bitcoin/blk0001.dat
2012-05-26 1498248084 /etc/bitcoin/blk0001.dat
2012-05-27 1508681378 /etc/bitcoin/blk0001.dat
2012-05-28 1522815402 /etc/bitcoin/blk0001.dat
2012-05-29 1534559641 /etc/bitcoin/blk0001.dat
2012-05-30 1548519990 /etc/bitcoin/blk0001.dat
2012-05-31 1559021061 /etc/bitcoin/blk0001.dat
2012-06-01 1569564941 /etc/bitcoin/blk0001.dat
2012-06-02 1580575393 /etc/bitcoin/blk0001.dat
2012-06-03 1587946725 /etc/bitcoin/blk0001.dat
2012-06-04 1606402628 /etc/bitcoin/blk0001.dat
2012-06-05 1627834056 /etc/bitcoin/blk0001.dat
2012-06-06 1640348229 /etc/bitcoin/blk0001.dat
2012-06-07 1652350639 /etc/bitcoin/blk0001.dat
2012-06-08 1666167538 /etc/bitcoin/blk0001.dat
2012-06-09 1677896481 /etc/bitcoin/blk0001.dat
2012-06-10 1693645887 /etc/bitcoin/blk0001.dat
2012-06-11 1709933345 /etc/bitcoin/blk0001.dat
2012-06-12 1722759164 /etc/bitcoin/blk0001.dat
2012-06-13 1740414976 /etc/bitcoin/blk0001.dat
2012-06-14 1764025373 /etc/bitcoin/blk0001.dat
2012-06-15 1793373477 /etc/bitcoin/blk0001.dat
2012-06-16 1816779031 /etc/bitcoin/blk0001.dat
2012-06-17 1833252231 /etc/bitcoin/blk0001.dat
2012-06-18 1852905491 /etc/bitcoin/blk0001.dat
2012-06-19 1870037682 /etc/bitcoin/blk0001.dat
2012-06-20 1887288369 /etc/bitcoin/blk0001.dat
2012-06-21 1900401914 /etc/bitcoin/blk0001.dat
2012-06-22 1912466805 /etc/bitcoin/blk0001.dat
2012-06-23 1923995757 /etc/bitcoin/blk0001.dat
2012-06-24 1933990532 /etc/bitcoin/blk0001.dat
2012-06-25 1944690092 /etc/bitcoin/blk0001.dat
2012-06-26 1959698111 /etc/bitcoin/blk0001.dat
2012-06-27 1972913174 /etc/bitcoin/blk0001.dat
2012-06-28 1986538427 /etc/bitcoin/blk0001.dat
2012-06-29 1996448635 /etc/bitcoin/blk0001.dat
2012-06-30 2006916132 /etc/bitcoin/blk0001.dat
2012-07-01 2015973705 /etc/bitcoin/blk0001.dat
2012-07-02 2023618409 /etc/bitcoin/blk0001.dat
2012-07-03 2035063345 /etc/bitcoin/blk0001.dat
2012-07-04 2043890164 /etc/bitcoin/blk0001.dat
2012-07-05 2054166307 /etc/bitcoin/blk0001.dat
2012-07-06 2065055232 /etc/bitcoin/blk0001.dat
2012-07-07 2076545899 /etc/bitcoin/blk0001.dat
2012-07-08 2086724069 /etc/bitcoin/blk0001.dat
2012-07-09 2096537543 /etc/bitcoin/blk0001.dat
2012-07-10 2097197999 /etc/bitcoin/blk0001.dat 12008809 /etc/bitcoin/blk0002.dat
2012-07-11 2097197999 /etc/bitcoin/blk0001.dat 27005578 /etc/bitcoin/blk0002.dat
2012-07-12 2097197999 /etc/bitcoin/blk0001.dat 39748075 /etc/bitcoin/blk0002.dat
2012-07-13 2097197999 /etc/bitcoin/blk0001.dat 49326320 /etc/bitcoin/blk0002.dat
2012-07-14 2097197999 /etc/bitcoin/blk0001.dat 62794757 /etc/bitcoin/blk0002.dat
2012-07-15 2097197999 /etc/bitcoin/blk0001.dat 71811369 /etc/bitcoin/blk0002.dat
2012-07-16 2097197999 /etc/bitcoin/blk0001.dat 85398455 /etc/bitcoin/blk0002.dat
2012-07-17 2097197999 /etc/bitcoin/blk0001.dat 99914073 /etc/bitcoin/blk0002.dat
2012-07-18 2097197999 /etc/bitcoin/blk0001.dat 114831638 /etc/bitcoin/blk0002.dat
2012-07-19 2097197999 /etc/bitcoin/blk0001.dat 130607878 /etc/bitcoin/blk0002.dat
2012-07-20 2097197999 /etc/bitcoin/blk0001.dat 147820861 /etc/bitcoin/blk0002.dat
2012-07-21 2097197999 /etc/bitcoin/blk0001.dat 165420763 /etc/bitcoin/blk0002.dat
2012-07-22 2097197999 /etc/bitcoin/blk0001.dat 178572030 /etc/bitcoin/blk0002.dat
2012-07-23 2097197999 /etc/bitcoin/blk0001.dat 192501692 /etc/bitcoin/blk0002.dat
2012-07-24 2097197999 /etc/bitcoin/blk0001.dat 206724726 /etc/bitcoin/blk0002.dat
2012-07-25 2097197999 /etc/bitcoin/blk0001.dat 217679969 /etc/bitcoin/blk0002.dat
2012-07-26 2097197999 /etc/bitcoin/blk0001.dat 230471863 /etc/bitcoin/blk0002.dat
2012-07-27 2097197999 /etc/bitcoin/blk0001.dat 243038699 /etc/bitcoin/blk0002.dat
2012-07-28 2097197999 /etc/bitcoin/blk0001.dat 255916653 /etc/bitcoin/blk0002.dat
2012-07-29 2097197999 /etc/bitcoin/blk0001.dat 269434652 /etc/bitcoin/blk0002.dat
2012-07-30 2097197999 /etc/bitcoin/blk0001.dat 285548558 /etc/bitcoin/blk0002.dat
2012-07-31 2097197999 /etc/bitcoin/blk0001.dat 300996976 /etc/bitcoin/blk0002.dat
2012-08-01 2097197999 /etc/bitcoin/blk0001.dat 318611215 /etc/bitcoin/blk0002.dat
2012-08-02 2097197999 /etc/bitcoin/blk0001.dat 331520948 /etc/bitcoin/blk0002.dat
2012-08-03 2097197999 /etc/bitcoin/blk0001.dat 344838301 /etc/bitcoin/blk0002.dat
2012-08-04 2097197999 /etc/bitcoin/blk0001.dat 356550607 /etc/bitcoin/blk0002.dat
2012-08-05 2097197999 /etc/bitcoin/blk0001.dat 370743850 /etc/bitcoin/blk0002.dat
2012-08-06 2097197999 /etc/bitcoin/blk0001.dat 385511040 /etc/bitcoin/blk0002.dat
2012-08-07 2097197999 /etc/bitcoin/blk0001.dat 399372092 /etc/bitcoin/blk0002.dat
2012-08-08 2097197999 /etc/bitcoin/blk0001.dat 412823715 /etc/bitcoin/blk0002.dat
2012-08-09 2097197999 /etc/bitcoin/blk0001.dat 427681293 /etc/bitcoin/blk0002.dat
2012-08-10 2097197999 /etc/bitcoin/blk0001.dat 440175151 /etc/bitcoin/blk0002.dat
2012-08-11 2097197999 /etc/bitcoin/blk0001.dat 452568162 /etc/bitcoin/blk0002.dat
2012-08-12 2097197999 /etc/bitcoin/blk0001.dat 466195766 /etc/bitcoin/blk0002.dat
2012-08-13 2097197999 /etc/bitcoin/blk0001.dat 483163148 /etc/bitcoin/blk0002.dat
2012-08-14 2097197999 /etc/bitcoin/blk0001.dat 501741802 /etc/bitcoin/blk0002.dat
2012-08-15 2097197999 /etc/bitcoin/blk0001.dat 520557035 /etc/bitcoin/blk0002.dat
2012-08-16 2097197999 /etc/bitcoin/blk0001.dat 545470935 /etc/bitcoin/blk0002.dat
2012-08-17 2097197999 /etc/bitcoin/blk0001.dat 562766557 /etc/bitcoin/blk0002.dat
2012-08-18 2097197999 /etc/bitcoin/blk0001.dat 581570416 /etc/bitcoin/blk0002.dat
2012-08-19 2097197999 /etc/bitcoin/blk0001.dat 596226301 /etc/bitcoin/blk0002.dat
2012-08-20 2097197999 /etc/bitcoin/blk0001.dat 614725587 /etc/bitcoin/blk0002.dat
2012-08-21 2097197999 /etc/bitcoin/blk0001.dat 630696938 /etc/bitcoin/blk0002.dat
2012-08-22 2097197999 /etc/bitcoin/blk0001.dat 646700956 /etc/bitcoin/blk0002.dat
2012-08-23 2097197999 /etc/bitcoin/blk0001.dat 661270387 /etc/bitcoin/blk0002.dat
2012-08-24 2097197999 /etc/bitcoin/blk0001.dat 674000481 /etc/bitcoin/blk0002.dat
2012-08-25 2097197999 /etc/bitcoin/blk0001.dat 690126369 /etc/bitcoin/blk0002.dat
2012-08-26 2097197999 /etc/bitcoin/blk0001.dat 702519764 /etc/bitcoin/blk0002.dat
2012-08-27 2097197999 /etc/bitcoin/blk0001.dat 716207603 /etc/bitcoin/blk0002.dat
2012-08-28 2097197999 /etc/bitcoin/blk0001.dat 729101108 /etc/bitcoin/blk0002.dat
2012-08-29 2097197999 /etc/bitcoin/blk0001.dat 744126478 /etc/bitcoin/blk0002.dat
2012-08-30 2097197999 /etc/bitcoin/blk0001.dat 755980806 /etc/bitcoin/blk0002.dat
2012-08-31 2097197999 /etc/bitcoin/blk0001.dat 772855156 /etc/bitcoin/blk0002.dat
2012-09-01 2097197999 /etc/bitcoin/blk0001.dat 789335949 /etc/bitcoin/blk0002.dat
2012-09-02 2097197999 /etc/bitcoin/blk0001.dat 804388646 /etc/bitcoin/blk0002.dat
2012-09-03 2097197999 /etc/bitcoin/blk0001.dat 821006790 /etc/bitcoin/blk0002.dat
2012-09-04 2097197999 /etc/bitcoin/blk0001.dat 836312363 /etc/bitcoin/blk0002.dat
2012-09-05 2097197999 /etc/bitcoin/blk0001.dat 854129159 /etc/bitcoin/blk0002.dat
2012-09-06 2097197999 /etc/bitcoin/blk0001.dat 873526155 /etc/bitcoin/blk0002.dat
2012-09-07 2097197999 /etc/bitcoin/blk0001.dat 889422332 /etc/bitcoin/blk0002.dat
2012-09-08 2097197999 /etc/bitcoin/blk0001.dat 903365802 /etc/bitcoin/blk0002.dat
2012-09-09 2097197999 /etc/bitcoin/blk0001.dat 916624640 /etc/bitcoin/blk0002.dat
2012-09-10 2097197999 /etc/bitcoin/blk0001.dat 930943985 /etc/bitcoin/blk0002.dat
2012-09-11 2097197999 /etc/bitcoin/blk0001.dat 944491878 /etc/bitcoin/blk0002.dat
2012-09-12 2097197999 /etc/bitcoin/blk0001.dat 960655424 /etc/bitcoin/blk0002.dat
2012-09-13 2097197999 /etc/bitcoin/blk0001.dat 972003589 /etc/bitcoin/blk0002.dat
2012-09-14 2097197999 /etc/bitcoin/blk0001.dat 987247808 /etc/bitcoin/blk0002.dat
2012-09-15 2097197999 /etc/bitcoin/blk0001.dat 1001929255 /etc/bitcoin/blk0002.dat
2012-09-16 2097197999 /etc/bitcoin/blk0001.dat 1014553077 /etc/bitcoin/blk0002.dat
2012-09-17 2097197999 /etc/bitcoin/blk0001.dat 1026133089 /etc/bitcoin/blk0002.dat
2012-09-18 2097197999 /etc/bitcoin/blk0001.dat 1038611622 /etc/bitcoin/blk0002.dat
2012-09-19 2097197999 /etc/bitcoin/blk0001.dat 1053155737 /etc/bitcoin/blk0002.dat
2012-09-20 2097197999 /etc/bitcoin/blk0001.dat 1067596678 /etc/bitcoin/blk0002.dat
2012-09-21 2097197999 /etc/bitcoin/blk0001.dat 1080601402 /etc/bitcoin/blk0002.dat
2012-09-22 2097197999 /etc/bitcoin/blk0001.dat 1094006521 /etc/bitcoin/blk0002.dat
2012-09-23 2097197999 /etc/bitcoin/blk0001.dat 1105101587 /etc/bitcoin/blk0002.dat
2012-09-24 2097197999 /etc/bitcoin/blk0001.dat 1118726220 /etc/bitcoin/blk0002.dat
2012-09-25 2097197999 /etc/bitcoin/blk0001.dat 1129992308 /etc/bitcoin/blk0002.dat
2012-09-26 2097197999 /etc/bitcoin/blk0001.dat 1142190581 /etc/bitcoin/blk0002.dat
2012-09-27 2097197999 /etc/bitcoin/blk0001.dat 1156590441 /etc/bitcoin/blk0002.dat
2012-09-28 2097197999 /etc/bitcoin/blk0001.dat 1169408710 /etc/bitcoin/blk0002.dat

I don't keep historic data on blkindex.dat, but it is currently 1079406592 bytes.  (Currently meaning right now, not when the snapshot of the block000?.dat files were recorded.)  Oh, and these are my files, not the files.  Yours might be a bit different depending on which orphans your node saw.

I'm not sure about how to move it in Windows.  I *think* you can shut down, copy all the files, edit your bitcoin.conf to include a datadir=D:\blah\ line, and start again.  Pay attention if you do this, using the datadir= option changes where the client looks for EVERYTHING except the bitcoin.conf.  But I'm not sure about that, you may need to use something more elaborate, like a NTFS junction.  The default data dir in Windows is %APPDATA%\Bitcoin

Sadly, it isn't really compressible in the usual way.  Almost everything in it is high entropy, so it won't compress much, if any.  The devs are working on other ways to distribute the files and reduce their impact.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Ascholten on September 28, 2012, 10:34:05 PM
you would think that they could break them into say 100 meg pieces that can be loaded as that one chunk, already 'pre figured out' or whatever you want to call it, and then maybe the last 30 days trickle in as it does now.

How about, after a transaction has been verified a few thousand times, umm duuh it's VALID, lets move it to an inactive block chain or something.  I know each piece works off the previous but we we take a 100 meg
piece say 'THIS' is the answer from that ... that gets fed to the next transaction, it might speed things up a bit.

Aaron


Title: Re: Size of BTC blockchain centuries from now...
Post by: solareclipse64236 on September 28, 2012, 10:37:28 PM
wtf do you mean centuries from now?

it's only good until 2120 something


Title: Re: Size of BTC blockchain centuries from now...
Post by: Ascholten on September 28, 2012, 10:43:14 PM
by that time I see an entirely new form of currency and bit coins will be about as obsolete as 8 track tapes.

Aaron


Title: Re: Size of BTC blockchain centuries from now...
Post by: Desolator on September 29, 2012, 06:15:25 AM
wtf do you mean centuries from now?

it's only good until 2120 something
I better correct that before people fill up their flamethrowers.  It's only going to keep being created for <100 years :P it'll still be "good" and useful lol.

Btw my system's not running Linux but don't hate, at least I recoginzed that as Linux from my Redhat training lol.  That does answer my Q since I assume that means it's around 1028MB but just so I know for future reference, aww fuck it, I ran a search :P it's in C:\Users\[your username]\AppData\Roaming\Bitcoin\

...except mine's 2,048,142KB for blk0001.dat and 1,100,784KB for blk0002.dat and 1,030,936KB for blkindex.dat.

Btw what precisely are each of those?


Title: Re: Size of BTC blockchain centuries from now...
Post by: Yurock on September 29, 2012, 06:31:29 AM
...except mine's 2,048,142KB for blk0001.dat and 1,100,784KB for blk0002.dat and 1,030,936KB for blkindex.dat.

Btw what precisely are each of those?
https://en.bitcoin.it/wiki/Data_directory#Files
Blockchain data is split in 2GB files.


Title: Re: Size of BTC blockchain centuries from now...
Post by: kjj on September 29, 2012, 06:48:02 AM
by that time I see an entirely new form of currency and bit coins will be about as obsolete as 8 track tapes.

Check your (physical) wallet.  The 8-track tapes are in there.  The entirely new form of currency is here.


Title: Re: Size of BTC blockchain centuries from now...
Post by: kjj on September 29, 2012, 06:55:15 AM
wtf do you mean centuries from now?

it's only good until 2120 something
I better correct that before people fill up their flamethrowers.  It's only going to keep being created for <100 years :P it'll still be "good" and useful lol.

Btw my system's not running Linux but don't hate, at least I recoginzed that as Linux from my Redhat training lol.  That does answer my Q since I assume that means it's around 1028MB but just so I know for future reference, aww fuck it, I ran a search :P it's in C:\Users\[your username]\AppData\Roaming\Bitcoin\

...except mine's 2,048,142KB for blk0001.dat and 1,100,784KB for blk0002.dat and 1,030,936KB for blkindex.dat.

Btw what precisely are each of those?

There isn't precise answer.  The blocks are just appended to the block file(s), as they come in.  Each node has a (potentially) unique view of orphan blocks.


Title: Re: Size of BTC blockchain centuries from now...
Post by: misterbigg on September 29, 2012, 03:32:58 PM
In 1980 a 26 MB hard drive cost ~$5,000 (or $193,000,000 per TB).
Obviously angry birds isn't viable.  I mean who is going to spend a couple hundred dollars in storage on a free game. :)

I paid $800 for a ten megabyte hard drive in 1987.


Title: Re: Size of BTC blockchain centuries from now...
Post by: wumpus on September 30, 2012, 11:37:00 AM
Ooh the far future, cool.

(/Charles Stross mode on)

Humanity in 2500AD only very superficially resembles that of today. After a few recompilations and refactorings of the underlying mind substrate, and after converting most of the matter in the solar system to computronium, the concept of a human as we know it today seems pretty quaint.

This general purpose programmable material makes it possible to store information at a density never even imagined, by rearranging matter at a scale of particles not yet known today. And there are rumors of other civilizations, far away in the Magellanic cloud, storing information directly in the quantum state by performing a timing attack on the underlying fabric of spacetime.

One of the weakly godlike intelligences decides to use their spare cycles in the Jupiter Brain to compute the Kolmogorov complexity of the block chain, which at that point in time consists of 10^20 bytes of audit trail of artificially intelligent financial instruments solving the problem of interstellar trade between relativistic frames of reference...

(/Charles Stross mode off)


Title: Re: Size of BTC blockchain centuries from now...
Post by: Ascholten on September 30, 2012, 11:33:06 PM
I have a feeling within 20 years, money will be dna encoded or something and our 'wallets' are kept right on / as part of our body,  all this silly paper / metal disks, and virtual dollars and bitcoins will be long gone.

Aaron


Title: Re: Size of BTC blockchain centuries from now...
Post by: Dabs on October 01, 2012, 06:00:34 AM
No one would want anything permanently stuck on our body (except tattoos). There are movies about this, even old ones.

There would be no more anonymity (which can even be more valuable than many other things) or privacy if our public keys (or private keys) are embedded in our body.

A token might work, but people would be sure to shield them (like RFID passports and credit cards / smart cards.)


Title: Re: Size of BTC blockchain centuries from now...
Post by: ragnard on October 01, 2012, 08:42:37 PM
This is an important conversation to be having!

I've been concerned about the large blockchain since I first started studying and using bitcoin in 2011.  I recently installed the Satoshi client on a new PC and it took many hours to download/calculate the blockchain.  With so many users now having fast broadband Internet access, the size of the chain isn't the killer.  It is the huge I/O tasks involved.  I have been trying the Satoshi client out in a Virtual Box Windows 7 image and it is nearly unusable for 2-3 hours if I haven't run it for a few days and the client has to catch back up.  The hard drive just is maxed out making the physical machine nearly unusable.  I've been looking at alternative clients that don't require the full block chain and am glad to see work progressing in that area.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Mushoz on October 01, 2012, 08:48:30 PM
This is an important conversation to be having!

I've been concerned about the large blockchain since I first started studying and using bitcoin in 2011.  I recently installed the Satoshi client on a new PC and it took many hours to download/calculate the blockchain.  With so many users now having fast broadband Internet access, the size of the chain isn't the killer.  It is the huge I/O tasks involved.  I have been trying the Satoshi client out in a Virtual Box Windows 7 image and it is nearly unusable for 2-3 hours if I haven't run it for a few days and the client has to catch back up.  The hard drive just is maxed out making the physical machine nearly unusable.  I've been looking at alternative clients that don't require the full block chain and am glad to see work progressing in that area.

In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. :)


Title: Re: Size of BTC blockchain centuries from now...
Post by: SgtSpike on October 01, 2012, 09:03:27 PM
This is an important conversation to be having!

I've been concerned about the large blockchain since I first started studying and using bitcoin in 2011.  I recently installed the Satoshi client on a new PC and it took many hours to download/calculate the blockchain.  With so many users now having fast broadband Internet access, the size of the chain isn't the killer.  It is the huge I/O tasks involved.  I have been trying the Satoshi client out in a Virtual Box Windows 7 image and it is nearly unusable for 2-3 hours if I haven't run it for a few days and the client has to catch back up.  The hard drive just is maxed out making the physical machine nearly unusable.  I've been looking at alternative clients that don't require the full block chain and am glad to see work progressing in that area.
It is pretty amazing how long it takes these days... I had a client that was updated through block 135,000 or so, then turned off for months.  Started it back up the other day, and it took 3 days on a 1TB WD Black drive to finally get up to date - HDD crunching away the whole time.


Title: Re: Size of BTC blockchain centuries from now...
Post by: ragnard on October 01, 2012, 09:03:44 PM
In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. :)

This is very good news indeed!


Title: Re: Size of BTC blockchain centuries from now...
Post by: Dabs on October 02, 2012, 03:02:54 AM
If you have the RAM and hardware, maybe put your datadir inside a ramdrive. At least until it was updated.


Title: RAM drive
Post by: Yurock on October 02, 2012, 03:35:26 AM
If you have the RAM and hardware, maybe put your datadir inside a ramdrive. At least until it was updated.
This is the only remedy I see as of now. And I'm afraid that transaction history will possibly grow in size faster than average RAM. So, even this method may not be an option in the near future.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Desolator on October 02, 2012, 04:01:59 AM
In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. :)

How would that possibly work?  Everyone would download a new version of the blockchain database...from each other? When nobody has it?  Lol, so the original releaser of the fully converted database would be able to put whatever the hell they wanted in it :P So it'd have to be a very lengthy and difficult conversion process or a flat switch over supporting two databases, which is also not ideal.


Title: Re: Size of BTC blockchain centuries from now...
Post by: kjj on October 02, 2012, 04:17:27 AM
In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. :)

How would that possibly work?  Everyone would download a new version of the blockchain database...from each other? When nobody has it?  Lol, so the original releaser of the fully converted database would be able to put whatever the hell they wanted in it :P So it'd have to be a very lengthy and difficult conversion process or a flat switch over supporting two databases, which is also not ideal.

Erm.  I'm not sure where to start.

The blocks aren't in the database, they are just stuffed into files, and those files will not be changing at all.  What goes in the database is just index information so that blocks can be found quickly when needed.

The network passes blocks around, not files.  There is no need to distribute "new" database files.  New clients that don't have the blocks loaded will continue to load them as usual, by asking the network for them.  I haven't been following the work on leveldb, but I see no reason why the client couldn't include both sets of database libraries so that people upgrading can keep reading their old indexes while they generate the new ones.

And, I promise to leave at least one of my personal nodes running an old version for quite a while, just in case.


Title: Re: Size of BTC blockchain centuries from now...
Post by: jgarzik on October 02, 2012, 05:01:18 AM
In the next release, they will most likely make the switch to levelDB, which will be significantly faster in disk I/O. :)

How would that possibly work?  Everyone would download a new version of the blockchain database...from each other? When nobody has it?  Lol, so the original releaser of the fully converted database would be able to put whatever the hell they wanted in it :P So it'd have to be a very lengthy and difficult conversion process or a flat switch over supporting two databases, which is also not ideal.

The block format used on the network has not changed.  It is underlying database index on-disk that is changing.

It is trivial to rebuild the database index:  just delete blk*.dat, and download fresh from the network.

The blockchain data itself has not changed, and continues to be self-verifying (integrity protected by hash).



Title: Re: Size of BTC blockchain centuries from now...
Post by: runeks on October 02, 2012, 10:47:35 AM
My projections from looking at the following graph tells me we will have 10˛⁴ GB hard drives in the year 2120.

http://upload.wikimedia.org/wikipedia/commons/9/90/Hard_drive_capacity_over_time.svg

Ie. if I just project the line out to the year 2120, it tells me that - at that point in time - hard drives will have a capacity of 1,000 billion billion terabytes.

So to put that in perspective, a 100 byte file on a 10 TB hard drive today will, in the year 2120, have the same relative size as a 10 TB file on a 1,000 billion billion TB hard drive.

So the 100 bytes that what we now think of as a tiny amount of data (about three times the size of an ECC key) will be equivalent to 10 TB in the year 2120.

If the projections hold. Personally, I don't think they will hold. I think widely available storage media will exceed these sizes going over 100 years into the future.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Desolator on October 02, 2012, 01:07:44 PM
I'm confused!  "Networks" cannot store data, they're networks.  So someone somewhere on some storage media has the actual block data, right?  I assumed it was everyone and that the most logical storage method would be a database and not a flat file.  I get the indexing part, whether it's were to be in a database with the blocks as a separate table or not, since it allows you to find a block super quickly.  But, if everyone deleted blk*.dat then who on the network are they going to download the new version from?  Nobody would have it, lol.  Unless it's generated by reindexing their local copy of the block chain that you're saying they don't have.  3GB is kinda big for an index file though, so aren't all the blk.dat files the chain data itself?


Title: Re: Size of BTC blockchain centuries from now...
Post by: luffy on October 02, 2012, 01:30:31 PM
all the problems and issues are solved as they arrived :)
Just think why BTC hasn't been introduced 20 years earlier!
I have faith in internet and its evolution ;)


Title: Re: Size of BTC blockchain centuries from now...
Post by: runeks on October 02, 2012, 02:00:52 PM
3GB is kinda big for an index file though, so aren't all the blk.dat files the chain data itself?
blk<num>.dat (blk0002.dat, blk0001.dat, etc. in the future) is the actual block chain data. blkindex.dat is the index file.


Title: Re: Size of BTC blockchain centuries from now...
Post by: jgarzik on October 02, 2012, 04:20:17 PM
I'm confused!  "Networks" cannot store data, they're networks.  So someone somewhere on some storage media has the actual block data, right?  I assumed it was everyone and that the most logical storage method would be a database and not a flat file.  I get the indexing part, whether it's were to be in a database with the blocks as a separate table or not, since it allows you to find a block super quickly.  But, if everyone deleted blk*.dat then who on the network are they going to download the new version from?  Nobody would have it, lol.  Unless it's generated by reindexing their local copy of the block chain that you're saying they don't have.

The entire network does not upgrade at the exact same moment.

There will be many not-yet-upgraded nodes that will serve blockchain data to those upgrading to a new database index.

Quote
3GB is kinda big for an index file though, so aren't all the blk.dat files the chain data itself?

3GB chain data
1GB index

is what I have here.




Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on March 01, 2013, 02:14:16 AM
Right now, there is a hard-coded limit of 1 megabyte per block.

If we assume that limit never changes, that gives:
 1MB per block * 6 blocks per hour * 24*365.25*200 = 10,519,200 MB

... or 10.5 terabytes for the maximum size of the entire blockchain over the next 200 years (somebody check my math, I'm really good at dropping zeroes).

I expect that in 200 years 10 terabytes of storage will cost a few pennies.


Now whether or not that 1 megabyte per block limit should go away is hotly debated, and will be debated more and more as transaction volume increases.

By principle I don't understand how this limit can be possibly kept under any circumstances of btc traffic growth. If one block is generated only every 10 min and shall contain *all* the transactions that have occurred during a 10 min period, and if the number of transactions per minute increases dramatically in the future, then the block size has a lower limit that is determined by this number of transactions per 10 minutes, because the blockchain contains all the information of all transactions, which requires non-zero memory space.

Example: Let's assume that in e.g. 20 years from now there are 1 billion btc transactions being carried out every 10 minutes, which is not necessarily completly unrealistic, assuming >20 billion people on earth by that time, plus companies and computers carrying out automized transactions for certain financial purposes all day long.
Let's further assume that one transaction that is recorded in the blockchain occupies at least a few bytes of storage to contain all the transaction information. In lack of detailed knowledge of the bitcoin protocol, I am making the conservative assumption here that 50 bytes of storage are required per transaction (containing input address(es), output address(es), amount(s) etc.).

With these assumptions, the blockchain would grow by 50 GB every 10 minutes, or 7.2 TB per day, or 2630 TB per year.

2630 TB per year looks a lot, but it is certainly something well feasible by certain nodes already nowadays.

However, this number is still conservative! Theroretically, this number can be much higher, in fact infinite, whereas the storage capability of any technology cannot be infinite on a finite planet, given the fact that the number of atoms on earth are finite (ca. 10^50) and assuming that we will never be able to store more bits of information on earth than the number of atoms on earth. Hence, if the transaction volumne really gets too high, one has by principle think of another "format" to safe the bitcoin network state: Instead of storing the limit-less transaction history, one may instead have to store the btc adress associated to each satoshi, which leads to a finite rather than infinite worst-case memory requirement:
In the worst case, every satoshi resides on a different btc address. There are 21e6 x 1e8 = 2.1e15 = 2.1 million billion satoshis in existence. If one bitcoin address has 20 bytes of size (again this is a guess in lack of better knowledge, but should be not too wrong), then such a data base that captures the complete state of the whole bitcoin network at a given point in time would be 2.1e15 x 20 bytes in size, i.e. = 42e15 bytes = 42000 TBytes.

My conclusion: With a storage of ca. 42000 TB one could store the complete bitcoin network state (not transaction history) any time in the future! This storage is well within the reach of technological feasability, even today (you could buy this storage today for less than 4 million USD). Hence, there is no theoretical physical limit that prevents future expansion of the bitcoin system. In the worst case however one may have to transition the system in some far future from a "full transaction history" record to a "current network state" format, or a mixed form like "current network state at time t_0 plus differential trade history after t_0", where different nodes may use different times t_0 depending on their individual storage capabilities.




Title: Re: Size of BTC blockchain centuries from now...
Post by: misterbigg on March 01, 2013, 02:58:56 AM
Right now, there is a hard-coded limit of 1 megabyte per block.

Oh my GOD are you kidding me? There's a hard coded limit on the number of transactions? We must fix this immediately *snicker*

 :D  :D  ;D


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on March 01, 2013, 03:30:15 AM
Didn't you see the date on this thread?


Title: Re: Size of BTC blockchain centuries from now...
Post by: Yurock on March 01, 2013, 06:49:38 PM
Block size limit is artificial and will be adjusted as needed in the future. However, raising limits opens the network to flood. Increased future transaction fees are supposed keep transaction volume within manageable range. Currently this is my only hope.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on March 02, 2013, 12:58:31 AM
So does this means that due to today's 1 MB limit per 10 min (i.e. per block), if the number of transactions get so large that more than 1 MB of transaction data is generated every 10 min, then some transactions will never ever make it into the blockchain, if their transaction fees are too low?
Then this means that the queue of transactions that are waiting to get into the blockchain will grow larger and larger all the time, because the rate at which new transactions are created (> 1 MB/10 min) would be higher than the rate at which transactions could be processed (== at maximum 1 MB/10min).

If this is correct, then there would be the following consequences for the future of the bitcoin system, as transaction volume increases:
(1) Only transactions with sufficiently high transaction fees will make it into the blockchain at all.
(2) The Bitcoin clients should get a feature to revert transactions that are not yet in the blockchain, because if I transfer 1 BTC to address xxx with a low fee yyy, and after some days or weeks my transaction still does not show up in the blockchain, then I might want to revert my transaction and try again with a higher fee zzz > yyy.
(3) As a result of this mechanism, there will be a real "fight" to get one's transaction into the blockchain, so in practice this means that transactions will no longer cost "almost nothing", but to the contrary, transaction fees would soon become so high that for example micro-payments and small donations become prohibitive due to the high fees, and it would soon be cheaper again to use PayPal!
(4) As a result of (3), people will move to make bitcoin payments more and more inside "closed sub-systems", i.e. bitcoin banks that do their own bookkeeping on their customers' accounts without loading the blockchain. For example there could be a MtGox subsystem or a blockchain.info subsystem, to name just two. When I transfer BTCs from my MtGox account to another person's MtGox account, I would not use the blockchain, but the MtGox internal bookkeeping would carry out the transaction, just like in today's banking system. This would avoid transaction fees, so people will favor this variant. But this also means that many benefits of bitcoin as we know it today would vanish, and the whole bitcoin system would move towards a de-facto centralized system that is again built on trust into a cartel of a few "subsystems" (bitcoin banks), and these sub-systems may even run fractional reserve banking without their customers knowing about this.
So we would again end up with two kinds of money like in today's fiat money system: First the true bitcoin money (corresponding to today's fiat central bank money), and secondly the account balances of the "subsystems (=bitcoin banks)", that may finally run fractional reserve, like today's bank accounts.


Also, these sub-systems (bitcoin banks) would be vulnerable to government interference etc. So with such an evolution we will reach the point when the bitcoin experiment has finally missed its original goals and has failed. I think such an evolution should be avoided!

If my understanding is essentially correct, then I think the only solution to keep the bitcoin system open and avoid the outlined evolution towards closed sub-systems (="de-facto-bitcoin-banks") would really be to change the way that transactions are stored, as outlined in my last post, such that memory needs for saving the blockchain (be it the complete history or only the current state plus a short incremental history) does not increase infinitely.

Maybe my thoughts are relating to what may happen rather far in the future, but this future might also turn out to be nearer than what we think.

...Or am I missing some fundamental point here and all my worries are pointless?


Title: Re: Size of BTC blockchain centuries from now...
Post by: justusranvier on March 02, 2013, 01:20:08 AM
So does this means that due to today's 1 MB limit per 10 min (i.e. per block), if the number of transactions get so large that more than 1 MB of transaction data is generated every 10 min, then some transactions will never ever make it into the blockchain, if their transaction fees are too low?
Then this means that the queue of transactions that are waiting to get into the blockchain will grow larger and larger all the time, because the rate at which new transactions are created (> 1 MB/10 min) would be higher than the rate at which transactions could be processed (== at maximum 1 MB/10min).

If this is correct, then there would be the following consequences for the future of the bitcoin system, as transaction volume increases:
(1) Only transactions with sufficiently high transaction fees will make it into the blockchain at all.
(2) The Bitcoin clients should get a feature to revert transactions that are not yet in the blockchain, because if I transfer 1 BTC to address xxx with a low fee yyy, and after some days or weeks my transaction still does not show up in the blockchain, then I might want to revert my transaction and try again with a higher fee zzz > yyy.
(3) As a result of this mechanism, there will be a real "fight" to get one's transaction into the blockchain, so in practice this means that transactions will no longer cost "almost nothing", but to the contrary, transaction fees would soon become so high that for example micro-payments and small donations become prohibitive due to the high fees, and it would soon be cheaper again to use PayPal!
(4) As a result of (3), people will move to make bitcoin payments more and more inside "closed sub-systems", i.e. bitcoin banks that do their own bookkeeping on their customers' accounts without loading the blockchain. For example there could be a MtGox subsystem or a blockchain.info subsystem, to name just two. When I transfer BTCs from my MtGox account to another person's MtGox account, I would not use the blockchain, but the MtGox internal bookkeeping would carry out the transaction, just like in today's banking system. This would avoid transaction fees, so people will favor this variant. But this also means that many benefits of bitcoin as we know it today would vanish, and the whole bitcoin system would move towards a de-facto centralized system that is again built on trust into a cartel of a few "subsystems" (bitcoin banks), and these sub-systems may even run fractional reserve banking without their customers knowing about this.
So we would again end up with two kinds of money like in today's fiat money system: First the true bitcoin money (corresponding to today's fiat central bank money), and secondly the account balances of the "subsystems (=bitcoin banks)", that may finally run fractional reserve, like today's bank accounts.


Also, these sub-systems (bitcoin banks) would be vulnerable to government interference etc. So with such an evolution we will reach the point when the bitcoin experiment has finally missed its original goals and has failed. I think such an evolution should be avoided!

If my understanding is essentially correct, then I think the only solution to keep the bitcoin system open and avoid the outlined evolution towards closed sub-systems (="de-facto-bitcoin-banks") would really be to change the way that transactions are stored, as outlined in my last post, such that memory needs for saving the blockchain (be it the complete history or only the current state plus a short incremental history) does not increase infinitely.

Maybe my thoughts are relating to what may happen rather far in the future, but this future might also turn out to be nearer than what we think.

...Or am I missing some fundamental point here and all my worries are pointless?
I think this is very close to what will happen if the 1 MB limit is not increased before the demand for transactions catches up to the limit.

With regards to blockchain size, you might want to take a look at this: https://bitcointalk.org/index.php?topic=88208.0;all (https://bitcointalk.org/index.php?topic=88208.0;all)


Title: Re: Size of BTC blockchain centuries from now...
Post by: deepceleron on March 02, 2013, 03:12:05 AM
In 1985 the Cray-2 supercomputer was released, and was the fastest computer in the world for five years. It cost about $16 million in 1985 dollars. The memory was 256M 64k words, more than all previously produced Cray-1s combined - 2GB.  It had 1.9GFLOPS of processing power in it's fastest configuration - approximately equal to an iPad 2, and significantly less than the computer I'm typing on.

I think that technology might keep up with Bitcoin.




Title: Total transaction volume problems
Post by: Yurock on March 02, 2013, 10:56:59 AM
So does this means that due to today's 1 MB limit per 10 min (i.e. per block), if the number of transactions get so large that more than 1 MB of transaction data is generated every 10 min, then some transactions will never ever make it into the blockchain, if their transaction fees are too low?
No. We will not hit today's limit today. As for the near future, I already stated:
Block size limit is artificial and will be adjusted as needed in the future.

(2) The Bitcoin clients should get a feature to revert transactions that are not yet in the blockchain, because if I transfer 1 BTC to address xxx with a low fee yyy, and after some days or weeks my transaction still does not show up in the blockchain, then I might want to revert my transaction and try again with a higher fee zzz > yyy.
Yes. And also a way to add fees to existing transactions. AFAIK, it is already discussed by Bitcoin software developers, so we may see it implemented some time soon. Recipients of bitcoins will also be able to add to the fee.

(3) As a result of this mechanism, there will be a real "fight" to get one's transaction into the blockchain
I would use the word "compete". Competition is an important market force, and Bitcoin is designed to be governed by market forces.

so in practice this means that transactions will no longer cost "almost nothing"
Yes. Transactions cost something to the whole network. Every new transaction has to be propagated through the network and processed and stored (at least for some time) by every full node. Today, a large part of this cost is paid by newly generated coins, I think (but may be wrong). Let those who makes transactions (and thus supposedly needs them) pay most of this cost. Seems fair to me.

transaction fees would soon become so high that for example micro-payments and small donations become prohibitive due to the high fees, and it would soon be cheaper again to use PayPal!
Bitcoin is clearly not going to be generally suitable for payments of few cents. Other than that, I think, fees will not be prohibiting. From charts on blockchain.info, I estimate the average today's fee to be below equivalent of 4 U.S. cents. Multiply it by 5, and it will still seem quite acceptable to me.

(4) As a result of (3), people will move to make bitcoin payments more and more inside "closed sub-systems", i.e. bitcoin banks that do their own bookkeeping on their customers' accounts without loading the blockchain. For example there could be a MtGox subsystem or a blockchain.info subsystem, to name just two. When I transfer BTCs from my MtGox account to another person's MtGox account, I would not use the blockchain, but the MtGox internal bookkeeping would carry out the transaction, just like in today's banking system. This would avoid transaction fees, so people will favor this variant. But this also means that many benefits of bitcoin as we know it today would vanish, and the whole bitcoin system would move towards a de-facto centralized system that is again built on trust into a cartel of a few "subsystems" (bitcoin banks), and these sub-systems may even run fractional reserve banking without their customers knowing about this.
Remember, here you are talking only about micro-payments. Most people who need to transfer an amount like 10 BTC and up will not care to pay 0.01 BTC transaction fee. And fees are roughly per transaction, not per amount transferred. So, in the future, most micro-transactions are expected to be handled by other systems based on Bitcoin as a unit of value. As for larger transactions, Bitcoin is quite capable to handle them. So, only small (I think) part is going to move to systems that handle bitcoins indirectly. And it does not mean centralization. Cryptocurrencies of different kinds are being developed and launched, like Ripple and Open Transactions. They have no problem using Bitcoin as a unit of value. They may be more suitable for instant payments and micro-payments.

Also, these sub-systems (bitcoin banks) would be vulnerable to government interference etc.
Like Bitcoin to fiat exchanges, they may be points of failure. But the possible influence is limited by at least two factors:
  • Only a part of the whole Bitcoin economy will see an influence. Larger amounts of bitcoins that reside in normal Bitcoin wallets will not be affected.
  • There will be no monopoly. If, for example, you close one large Bitcoin payment processor, others will catch up.

solution to keep the bitcoin system open and avoid the outlined evolution towards closed sub-systems (="de-facto-bitcoin-banks") would really be to change the way that transactions are stored, as outlined in my last post
Your proposal has weak points, but the general idea is worthy, I think. The idea that since total Bitcoin supply is finite, amount of storage required to track every unit may also be finite and within capabilities of future systems.

...Or am I missing some fundamental point here and all my worries are pointless?
There are surely things to worry about, and different solutions to the problems have to be considered.


Title: Re: Size of BTC blockchain centuries from now...
Post by: misterbigg on March 02, 2013, 03:56:30 PM
So does this means that due to today's 1 MB limit per 10 min (i.e. per block), if the number of transactions get so large that more than 1 MB of transaction data is generated every 10 min, then some transactions will never ever make it into the blockchain, if their transaction fees are too low?

You're thinking along the right lines. My prediction:

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.



Title: Re: Size of BTC blockchain centuries from now...
Post by: zebedee on March 03, 2013, 11:20:05 AM
So does this means that due to today's 1 MB limit per 10 min (i.e. per block), if the number of transactions get so large that more than 1 MB of transaction data is generated every 10 min, then some transactions will never ever make it into the blockchain, if their transaction fees are too low?

You're thinking along the right lines. My prediction:

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

I believe your guess is reasonable until point 10.  After that, you're failing to understand the situation isn't stable at all, given all the competing interests, hence your 14th point in particular cannot happen.  The situation will resolve itself in the interests of the majority by the limit being increased.  The miners do not have the final say.


Title: Re: Total transaction volume problems
Post by: Michael_S on May 16, 2013, 08:49:12 PM
[...]
Yurock, after coming across this thread again after 2 months, I think I agree with all your points.

I think that's the way the bitcoin network is going to evolve.

So I would also say that lifting the 1 Mbyte limit is not really needed, because sooner or later anyway the "small" bitcoin traffic (and also retailer payments where we do not want to wait till the next confirmation at the checkpoint) will move to online wallet services. See also my future vision here (https://bitcointalk.org/index.php?topic=199353.msg2162947#msg2162947).


Title: Re: Size of BTC blockchain centuries from now...
Post by: nebulus on May 17, 2013, 01:42:42 AM
Didn't you see the date on this thread?

Clearly, I am ahead of times... or not... considering the date of this post...


Title: Re: Size of BTC blockchain centuries from now...
Post by: BitHits on May 19, 2013, 11:32:56 AM
I honestly dont think Bitcoin is going to last until the end of the decade.

The changes required to it to make it work for anyone that wants to use it for any purpose just screams AltCoin. Bitcoin was the model. Its certainly not going to end up being the solution.

Mark my words, By the end of the year. I'm predicting an AltCoin will unseat BitCoin.

Also good job Michael_S on necro'ing this thread :P


Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on May 19, 2013, 06:42:25 PM
I think people start realizing that increasing block size limit is not a solution but a new problem (e.g. http://keepbitcoinfree.org).

If block size limit is kept, I see no reason why bitcoin should fail.

The scenario that tx fees increase long-term and online wallet services start getting an increasing share in small "off-blockchain" transactions, makes sense to me as a natural and healthy evolution. Also, confirmation times of 10min are no problem then any more for shopping at retailers around the corner.

Also, all the infrastructure built now for Bitcoin won't be built for Alt-Coins soon - BTC is well ahead here.

The recent days and weeks and months an ever-increasing number of alt-coins has entered flooded the market. This does not reduce BTC value as it seems, but it seems to dilute the value of all other alt-coins. It appears that the market-cap of all altcoins together is one thing, and the market cap of Bitcoins alone is another thing (my impression - cannot prove it though). If this is true, it would show that people start realizing that alt coins are just copies for making their creators rich quickly, without any real long-term vision.

I have not yet seen a convincing Alt-Coins, most are dumb copies and some are conceptually interesting but not very transparent in terms of who is behind them, sometimes there seems to be just a single person (like PPC), which does not really create trust.
There is an initiative for "Netcoin" (MC2) - this appears to really become a community-project rather than a new single-person project, however some technical questions are yet unanswered in its concept - will be interesting to follow...


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on May 19, 2013, 08:55:36 PM
I think people start realizing that increasing block size limit is not a solution but a new problem (e.g. http://keepbitcoinfree.org).
If block size limit is kept, I see no reason why bitcoin should fail.

This video is FUD designed to further a personal agenda which is to be the renowned architect of the 3rd-party systems, which 99% of Bitcoin users will be forced to use when they are priced away from the blockchain.  

The essence of the video is that decentralization is at risk. Evidence is showing otherwise:
Bitcoin has a record number of active nodes, 350,000+, and this is increasing even as average block size is increasing.
http://bitnodes.io/

The recent days and weeks and months an ever-increasing number of alt-coins has entered flooded the market. This does not reduce BTC value as it seems, but it seems to dilute the value of all other alt-coins.

One of the alt-coins will have a flexible block size limit. If Bitcoin users find their transactions no longer work they will quickly use the alt coin which does work. Markets cleave to the best technology. Think Tesla's AC dominating world electrical systems instead of Edison's DC which has a niche role. Bitcoin has one chance for glory and a rigid block size limit will kill that chance.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on May 20, 2013, 01:18:59 AM
I think people start realizing that increasing block size limit is not a solution but a new problem (e.g. http://keepbitcoinfree.org).
If block size limit is kept, I see no reason why bitcoin should fail.

This video is FUD designed to further a personal agenda which is to be the renowned architect of the 3rd-party systems, which 99% of Bitcoin users will be forced to use when they are priced away from the blockchain.  

The essence of the video is that decentralization is at risk. Evidence is showing otherwise:
Bitcoin has a record number of active nodes, 350,000+, and this is increasing even as average block size is increasing.
http://bitnodes.io/

The recent days and weeks and months an ever-increasing number of alt-coins has entered flooded the market. This does not reduce BTC value as it seems, but it seems to dilute the value of all other alt-coins.

One of the alt-coins will have a flexible block size limit. If Bitcoin users find their transactions no longer work they will quickly use the alt coin which does work. Markets cleave to the best technology. Think Tesla's AC dominating world electrical systems instead of Edison's DC which has a niche role. Bitcoin has one chance for glory and a rigid block size limit will kill that chance.
Hmm, maybe the optimum block size limit is not 1 MB, but "infinity" is certainly the worst choice of all. It is also clear that at some point it will have to become limited... actually I came to this conclusion myself w/o personal agenda before I saw http://keepbitcoinfree.org, so it appeared quite logical to me. Anyway, one has to be very cautious about the pros and cons of increasing, or keeping, the block size limit, I think.

Remark: "http://bitnodes.io/" is interesting - seems that Finland, Norway, Sweden, Germany and Netherlands have the lead when relating the nb of nodes to the population. Interesting when considering where these countries are positioned in the world financial crisis.


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on May 20, 2013, 01:57:22 AM
Hmm, maybe the optimum block size limit is not 1 MB, but "infinity" is certainly the worst choice of all. It is also clear that at some point it will have to become limited...

1MB and "infinity" are the extremes.
There is a middle-ground which is a market-driven block size. This is achieved by a fees-market where there is competition for block-space. This was Satoshi's original vision, which still seems very sensible (not just because Satoshi liked it). The 25 BTC block reward is relatively high compared to fees, so a viable fees market won't occur until blocks are about 20 to 50Mb in size. Which is large but not outrageously so. The 1MB limit makes the fees market  stillborn, and never gives this essential feature of Bitcoin a chance to develop.


Title: Re: Size of BTC blockchain centuries from now...
Post by: runeks on May 20, 2013, 10:56:58 AM
Mark my words, By the end of the year. I'm predicting an AltCoin will unseat BitCoin.
Predictions are boring (and risk-free). How about making it interesting and entering an escrowed BTC bet with me on this? We can also do a combined BTC+LTC/(altcoin-of-your-choice) bet, if you wish.

Hmm, maybe the optimum block size limit is not 1 MB, but "infinity" is certainly the worst choice of all. It is also clear that at some point it will have to become limited... actually I came to this conclusion myself w/o personal agenda before I saw http://keepbitcoinfree.org, so it appeared quite logical to me.
Would you care to argue for your position, instead of just stating it?

It's not at all obvious to me why no block size limit is "certainly the worst choice of all". Nor is it clear to me "that at some point it will have to become limited".

Quote
Anyway, one has to be very cautious about the pros and cons of increasing, or keeping, the block size limit, I think.
Agreed.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on May 24, 2013, 11:47:32 PM
Hmm, maybe the optimum block size limit is not 1 MB, but "infinity" is certainly the worst choice of all. It is also clear that at some point it will have to become limited... actually I came to this conclusion myself w/o personal agenda before I saw http://keepbitcoinfree.org, so it appeared quite logical to me.
Would you care to argue for your position, instead of just stating it?

It's not at all obvious to me why no block size limit is "certainly the worst choice of all". Nor is it clear to me "that at some point it will have to become limited".
First of all, a lot of arguments (good argumetns I think) are given at http://keepbitcoinfree.org. It is easy to read and understand, so no point to re-iterate the arguments here. Everybody can read it and think about it for oneself.

In my own words, in essence if block size is unlimited, everyone can arbitrarily spam the blockchain without any risk and negligible cost, thereby driving up costs of operating a node of the bitcoin network and extremely accelerating the growth of blockchain size. As a result, only big players will remain as miners, creating a strong drive towards monopolizing the bitcoin network. This is the worst that could happen. Proponents of infinite or very large block size limit either do not see this, or have the interest of destroying bitcoin.

So I think an unlimited block size (or a too high limit) looks attractive short-term, but is not sustainable (i.e. not viable long-term), and since this can be seen well in advance, also mid-term adoption of bitcoin by the people is at risk, because people would see that bitcoin is at risk long-term.


PS: Moreover, long-term movement of transactions to off-blockchain systems is not a bad thing I think, because these operators would serve the non-tech-savvy masses (who don't know how to create safe cold storage etc.), while the minority of tech-savvy people (like >95% in this forum) may continue using the "proper" block chain, at least to a reasonable extend.


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on May 25, 2013, 12:18:57 AM
PS: Moreover, long-term movement of transactions to off-blockchain systems is not a bad thing I think, because these operators would serve the non-tech-savvy masses (who don't know how to create safe cold storage etc.), while the minority of tech-savvy people (like >95% in this forum) may continue using the "proper" block chain, at least to a reasonable extend.

Unfortunately Michael, that's the problem I have with a low inflexible block limit (like 1MB), because it is fees which will determine who gets their transactions onto the blockchain. In the vision of keepbitcoinfree it will only be the large 3rd party banks and services which can afford the high fees (in the order of $20 per transaction at least). The >95% of this forum, tech-savvy types, will be effectively banned from the blockchain. Then we can ask: "Who will run a Bitcoin node to maintain the decentralized network, when they can't afford to use the blockchain for everyday transactions?" Answer. No one. So the network becomes very centralized because only the bitcoin banks and 3rd party systems will run full nodes.


Title: Re: Size of BTC blockchain centuries from now...
Post by: gmaxwell on May 25, 2013, 12:44:33 AM
further a personal agenda which is to be the renowned architect of the 3rd-party systems
As far as I can tell this is a slanderous personal attack. It is unsupported by an information available to me. I must insist that you actually substantiate it or withdraw it.

Seriously, this is very uncool. If you don't believe you arguments are strong enough to stand on their own without hypothesizing evil on the part of your counter-parties then you should keep your views to yourself.  If people are attacked in this manner we _cannot_ have a civil conversation on this stuff.  No one but pure politicians will be willing to earnestly debate the subject when there exists a threat of character attacks like this.

If anything, if you want to attack Peter Todd and friends on this basis you should be criticizing them for spending too much time promoting tools as solutions to scaling relative to the amount of time they've spent actually creating them.  Lots of yap yap, but if this stuff is to be the great salvation against uncomfortable tradeoffs between scale and decentralization... show us the code!

Quote
The essence of the video is that decentralization is at risk. Evidence is showing otherwise:
Bitcoin has a record number of active nodes, 350,000+, and this is increasing even as average block size is increasing.
http://bitnodes.io/
The number of stable listening nodes is constant-to-decreasing based on the actually data available (the data collected by the DNS seed collectors).  I can only imagine that they're getting 350,000 based on counting up addr messages, which is a methodology that doesn't work and gives gibberish results.  Their data from actually connecting to nodes shows numbers like 6000 which sounds more realistic.  I certainly wish the big numbers were true, but I don't think they are.

Thats neither here nor there, as I don't think the argument is that there is currently a problem...  I point it out because I don't think the discussion is served by factually weak arguments.

That said, I personally think there currently are decentralization problems: For one, bitcoin.org will so no longer recommend bitcoin-qt: There is tremendous pressure to only recommend SPV clients and the new site when launched did so, and only stopped because multibit was constantly locking up at the time and had many other issues.  Blockchain sync stats (http://bitcoin.sipa.be/depth-small.png) appear to be suggesting, by the upward slope for the oldest blocks, that a significant fraction of all nodes that attempt syncing never finish.   Those issues are indirect— but when you consider that compromising _two_ computers (or their operators) is currently enough to control >>50% of the hash-power  you simply cannot say that we don't currently have severe decentralization problems.

Though it's not clear to me to what degree this is historical accident vs scaling induced, we'll know more once some new tools for improving mining decentralization come out in the not too distant future.


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on May 25, 2013, 01:11:41 AM
further a personal agenda which is to be the renowned architect of the 3rd-party systems
As far as I can tell this is a slanderous personal attack. It is unsupported by an information available to me. I must insist that you actually substantiate it or withdraw it.

Withdrawn.
I made the comment because of frustration that the debate on this crucial issue was moved from a civilized thread to a youtube video. I respect Peter's intellect, yet remain completely puzzled at the naive viewpoint that the video presents. He makes no attempt to measure decentralization, yet this is crucial to its message. It is only pieces of information, such as what you posted just now, which aids building an overall picture within which decisions on the block size can be made.




Title: Re: Size of BTC blockchain centuries from now...
Post by: gmaxwell on May 25, 2013, 01:48:07 AM
Withdrawn.
I made the comment because of frustration that the debate on this crucial issue was moved from a civilized thread to a youtube video. I respect Peter's intellect, yet remain completely puzzled at the naive viewpoint that the video presents. He makes no attempt to measure decentralization, yet this is crucial to its message. It is only pieces of information, such as what you posted just now, which aids building an overall picture within which decisions on the block size can be made.
Thank you!  And indeed. Lots more information is required all around. Some will be easier to get than others.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Michael_S on May 26, 2013, 06:07:48 AM
PS: Moreover, long-term movement of transactions to off-blockchain systems is not a bad thing I think, because these operators would serve the non-tech-savvy masses (who don't know how to create safe cold storage etc.), while the minority of tech-savvy people (like >95% in this forum) may continue using the "proper" block chain, at least to a reasonable extend.
Unfortunately Michael, that's the problem I have with a low inflexible block limit (like 1MB), because it is fees which will determine who gets their transactions onto the blockchain. In the vision of keepbitcoinfree it will only be the large 3rd party banks and services which can afford the high fees (in the order of $20 per transaction at least). The >95% of this forum, tech-savvy types, will be effectively banned from the blockchain. Then we can ask: "Who will run a Bitcoin node to maintain the decentralized network, when they can't afford to use the blockchain for everyday transactions?" Answer. No one. So the network becomes very centralized because only the bitcoin banks and 3rd party systems will run full nodes.
Solex, your arguments do not convince me at all.

First, the "20 USD" that you state is very far-fetched, way too high in my impression. If we consider that the "3rd party banks" (or "online wallet providers", as I would call them) mainly use the blockchain to transfer funds between them, just like in the fiat money system today private banks carry out electronic money transfers of real central bank money between each other, then the capacity of the blockchain would not even be close to exhausted from this sort of transaction. Private banks have to make such transaction today only once per day, so the "bandwidth" for such transactions is enormously low, and enough bandwidth would still be left for normal business bitcoin transactions.

But even if all business and private transactions were practically "banned" from the blockchain due to these 20 USD fees, I would in the end still see a big difference and advantage compared to today's fiat world: In today's world, private people and businesses have no access to electronic central bank money at all (just non-electronic "cash" is central bank money). The rest of today's electronic "money" is actually just liabilities of banks towards their customers. In the "new world", private people and businesses and banks would have equal access to "real" money (the "primary blockchain-bitcoins"), and no private person needs to put his life-time savings into bank accounts with consequences as we have recently seen in Cyprus.

Secondly and more importantly, I would draw exactly the opposite conclusion than you w.r.t decentralization of miners (=bitcoin network nodes)! Think about it, please. You seem to confuse the concepts of bitcoin USERS and bitcoin MINERS, or at least you seem not to separate these two concepts. If transaction fees grow to an equivalent of 20 USD/transactions as you suggest, then this means in tendency a centralization of USERS, i.e. mainly those who transfer large amounts of bitcoins (like online wallet service providers, private persons buying real estates, or big companies) will have the "privilege" to use the blockchain instead of off-blockchain transfers of liabilities (=equivalent to today's bank transfers). But this is of no relevance for the miners! From the MINER point of view, there is a certain amount of traffic going on, the miner does not care who is generating this traffic, whether a bank or a private person. Thanks to the high TX fees it is really profitable to set up an own miner for many people. And since the block size limit is relatively low, the bitcoin network is still scalable, i.e. HW expenses for setting up a miner are low, so many people will decide to setup miners --> we get the desired DEcentralization effect in terms of Miners=bitcoin network nodes.

In the other case (no block size limit), we have the opposite effect: Short-term, USERS will continue to be able to use the blockchain at low tx fees due to low competition between transactions. So miners will have lower revenues, which will mean that many miners are going to switch off. As time proceeds, the blockchain increases quickly, meaning higher and higher memory requirements for miners. This will be another negative cost factor for miners that will cause even more miners to switch off. --> we get the UNdesired centralization effect in terms of Miners.

To summarize:
  (*) Limited Block Size promotes...
  • ...Decentralization of MINERS (due to higher TX fees and lower blockchain size, making mining more profitable), but
  • ...Centralization of USERS (due to higher TX fees, more users or services get incentive to go "off-blockchain")

  (*) Unlimited Block Size promotes...
  • ...Centralization of MINERS (due to exploding blockchain size=higher mining hardware costs and less profitable mining due to lower TX fees), but
  • ...Decentralization of USERS (due to lower TX fees more users will continue using the blockchain directly)

So one has to make the best compromise. Clearly, if block size is too low (e.g. only ONE transaction per block, to make an extreme example), the network will become useless, people will loose interest, nobody will use it, and bitcoin dies. So in that sense we should be worried about Centralization of USERS.
But the current block size limit or 1 MB corresponds to ca. 1000 transactions per block (maybe 2000...), which is far from this point, as the current network already proves. So Centralization of Users is not to worry about.

Rather we should be worried about the Centralization of MINERS, which appears to be the main threat to the bitcoin network right now.

As long as tx fees are so low that services like SatoshiDice still operate over the blockchain, there is certainly no need to increase the block size limit. Once we approach the block size limit and SatoshiDice is "squeezed out", and we hit the blocksize limit again, people will first start to become more cautious about their transactions! I know it from myself, I used to make lots of "fun" and "test" transactions in the past, because they were so cheap. If Tx costs rise from let's say 0.5 cent to 10 or 20 cent, I will certainly reduce my unnecessary transactions substantially (which make up certainly more than 90% of my transactions today) without really feeling that the bitcoin network has become less valuable for me in essence. Other users will do the same. So there will be a natural evolution towards use of transactions only where really needed, and this is good. There is absolutely nothing wrong with the vision that in a very far future (assuming that bitcoin is really becoming the dominating currency in the world one day - which is far from certain) the vast majority of payments (like shopping etc.) are done off-blockchain via service providers. However, if we destroy the network before due to miner scalability and decentralization problems, bitcoin will certainly never reach that point.


(update: PS: 20 USD tx fee/transaction means ca. 30000 USD tx fee per block, or ca. 4 Million USD tx fee per day, or 1.5 Billion USD per year. Just to get an idea. Current block reward (currently dominating the fees) is ca. 3000 USD/block.)


Title: Re: Size of BTC blockchain centuries from now...
Post by: Peter Todd on May 26, 2013, 04:57:21 PM
If anything, if you want to attack Peter Todd and friends on this basis you should be criticizing them for spending too much time promoting tools as solutions to scaling relative to the amount of time they've spent actually creating them.  Lots of yap yap, but if this stuff is to be the great salvation against uncomfortable tradeoffs between scale and decentralization... show us the code!

With enemies like you, who needs friends? ;)

Of course, I can in turn respond that advocacy rather than code is a response to getting attacked for promoting my specific off-chain systems like fidelity-bonded banks - the more people who realize this is a problem and work on solutions the better. If they come up with solutions that are drastically different from what I've proposed, all the better, so long as they actually work. Personal attacks just make this inherently highly political argument even worse.

Thats neither here nor there, as I don't think the argument is that there is currently a problem...  I point it out because I don't think the discussion is served by factually weak arguments.

Yup. It's funny listening to the "but we're decentralized now!" argument, because that's exactly the conversation I had with the people at stonecanoe when I was making the video. Specifically we thought it was hilarious that we were essentially making an advocacy video where the "call to action" message for much of the target audience was "do nothing and everything will be ok"

SPV clients and big mining pools are a concern, but overall Bitcoin is fairly decentralized now. I want to keep it that way.


Title: Miners and transaction volumes
Post by: Yurock on May 27, 2013, 03:15:44 PM
In the other case (no block size limit), we have the opposite effect: Short-term, USERS will continue to be able to use the blockchain at low tx fees due to low competition between transactions. So miners will have lower revenues, which will mean that many miners are going to switch off.
I guess that larger blocks would have more total fees, despite the lower average fee. Consider block chain transactions as a service. The cheaper the service is, the greater is the turnover, because more people pay to the Bitcoin network and less to other payment processors. Of course, that holds true down to a certain extreme; a free service has zero turnover in terms of money. So, as long as fees are above some threshold, transaction volume is not a concern for miners. Even though their expenses increase (not significantly), they are still paid for the information they process. Additional gigabytes of required storage will not be a problem for miners. Most of a typical miner's expenses go to SHA2 bruteforce, which has no relation to the transaction volume.

Do we need a hard block size limit to keep fees above the profitability threshold? I think, no. Miners are free to choose what transactions to include in their blocks. A reasonable miner will just drop any transactions that don't worth inclusion. Unreasonable miners and attackers can produce blocks with lots of trash, but hopefully these will be too rare to affect other miners.

So, miners are unlikely to suffer from increased transaction volume. And who does suffer? Non-miner nodes do. They don't receive a compensation for their processing power and occupied storage. Block size limit is to benefit of users who run their own nodes. Setting up new nodes becomes harder with time, and increase in transaction volume makes it considerably worse. If large number of nodes is important for Bitcoin network health, we will need to motivate full-node operators somehow. Until we have a solution, we better keep transaction volume low. By the way, some foresee that most of full nodes will be run by miners and businesses that profit from Bitcoin in some other way.


Title: Re: Miners and transaction volumes
Post by: justusranvier on May 27, 2013, 03:24:33 PM
Until we have a solution,
https://bitcointalk.org/index.php?topic=204283.0 (https://bitcointalk.org/index.php?topic=204283.0)


Title: Re: Miners and transaction volumes
Post by: runeks on May 27, 2013, 04:58:46 PM
Even though their expenses increase (not significantly), they are still paid for the information they process. Additional gigabytes of required storage will not be a problem for miners. Most of a typical miner's expenses go to SHA2 bruteforce, which has no relation to the transaction volume.
Why would you say this?

My ancient 2.83 GHz Core 2 Quad can currently handle around 3000 transactions per second. If we assume an average transaction size of 250 bytes, that's a data rate of 730 KB/s, or 1.8 TB per month.

So your average old CPU can chug along for years without an upgrade, but you will have to buy a new 2 TB HDD every month.


Title: Full nodes
Post by: Yurock on May 27, 2013, 07:27:30 PM
https://bitcointalk.org/index.php?topic=204283.0 (https://bitcointalk.org/index.php?topic=204283.0)
That is a project that promises to make secure verification of new transactions and blocks possible without having the full block chain stored locally. It is also planned to use additional channels (BitTorrent) for distribution of old blocks to syncing nodes. Thus, the need in full nodes in their current form may be reduced. However, it will require a motivation for maintaining an additional block chain and distributing old data. Am I right?

runeks, I missed a point of your message.


Title: Re: Size of BTC blockchain centuries from now...
Post by: solex on May 28, 2013, 12:35:59 AM
First, the "20 USD" that you state is very far-fetched, way too high in my impression...

The track record of banks charging as much as they can for wire transfers is shameful.  Between $15 and $45 is cited here:
http://en.wikipedia.org/wiki/Wire_transfer#Regulation_and_price
The standard fee for international wire transfers is generally $25. No reason to expect the profit motive to weaken for Bitcoin banks. Also, if people pay this much now then blockchain fees could reach this level too.

The wire business should be bread and butter for Bitcoin to steal, but millions of such fiat transfers are done every day, well outside the current network capacity (even if SatoshiDice-like volume were zero, instead of 50% of current volume). Note that gamblers have a high tolerance to fees and Bitcoin may well prove to be a huge hit for the whole online gambling industry which could easily saturate the blocks by itself.

I have not yet advocated infinite blocks, just supported the idea of a flexible limit that might help the fees market develop by block space rationing. Until recently Bitcoin operated with a block limit that was effectively infinite because the number of transactions was far too small to trouble it. Then a soft-limit of 250KB was tried (to see how the network behaved), as well as 500KB later. As soon as the 250KB blocks approached saturation the limit needed raising because of users having unreasonable delays.
Fees are rising but probably due to client changes rather than block space rationing.
https://blockchain.info/charts/transaction-fees?showDataPoints=false&timespan=&show_header=true&daysAverageString=7&scale=0&address=

You make more points, but, have you read these threads?
The MAX_BLOCK_SIZE fork
https://bitcointalk.org/index.php?topic=140233.0
How a floating blocksize limit inevitably leads towards centralization
https://bitcointalk.org/index.php?topic=144895.0
Funding of network security with infinite block sizes
https://bitcointalk.org/index.php?topic=157141.0

To be clear, I am all for decentralization as well. This is not monolithic. Miners are one aspect, but also non-mining peering/propagating full nodes are another. It is the latter case which is hard to measure well. If there are 6,000 such full nodes then this seems much healthier than the mining situation where one miner has 25% of the network hashing power: http://www.asicminercharts.com/, let alone that only a few pools hash most of the blocks.

Until we have a solution,
https://bitcointalk.org/index.php?topic=204283.0 (https://bitcointalk.org/index.php?topic=204283.0)

This is a good part of the answer to block size concerns, and becoming more urgent.


Title: Re: Size of BTC blockchain centuries from now...
Post by: runeks on June 25, 2013, 05:26:27 PM
So one has to make the best compromise. Clearly, if block size is too low (e.g. only ONE transaction per block, to make an extreme example), the network will become useless, people will loose interest, nobody will use it, and bitcoin dies. So in that sense we should be worried about Centralization of USERS.
But the current block size limit or 1 MB corresponds to ca. 1000 transactions per block (maybe 2000...), which is far from this point, as the current network already proves. So Centralization of Users is not to worry about.
One thing I don't get is the following:

You say that the current block size limit of 1 MB is not a problem, because we're only seeing ~100KB blocks on average. But how is that an argument? If we just raise the size limit every time there is demand for it, why even have it in the first place? What purpose does it serve if we're going to adjust it manually anyway when transaction volume starts budging against the limit? A continually adjusted limit is not a limit.


Title: "Always high" block size limit
Post by: Yurock on June 26, 2013, 07:01:27 AM
A limit that is always above the average actual block size at least prevents an attacker from creating one enormous block.


Title: Re: Size of BTC blockchain centuries from now...
Post by: PerfectAgent on June 27, 2013, 06:14:12 PM
I thought that was the only intent behind block size.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Valerian77 on July 10, 2013, 12:01:06 AM
I do not see the actual problem.

True - the blockchain has an incredible length of 10GB now. And some BTC users might not want to handle this.

But ..

1. anybody is free to use a lightweight client

2. compression is part of any modern file or operating system

3. according to the statistics it is growing now by 5GB every 6 month - I think as long as this is not a traffic or computational problem it should not be a storage problem due to current hard drive sizes.

Where the heck is the point ? Finally there will be a group of miners, secondly a group of heavy weight client users and thirdly the crowd of lightweight client users. Maybe from a security point of view the situation becomes serious if the number of blockchain users drops under a certain level which I do not see now.

I use a heavyweight client currently mayself and still have no problem with the size.


Title: Re: "Always high" block size limit
Post by: runeks on July 10, 2013, 07:57:34 AM
A limit that is always above the average actual block size at least prevents an attacker from creating one enormous block.
This is a fair point.

But perhaps it would be wiser to include a built-in limit of, say, a rolling median or average of the last 1000 blocks instead.

On the other hand that would just introduce added complexity. Perhaps it's a good idea to transition to that eventually, but start out by manually increasing the limit.


Title: Verification
Post by: Yurock on July 12, 2013, 10:27:30 PM
I do not see the actual problem.
Problems may be not obvious now, but we need to be ready to scale. Now we have about 0.48 transactions per second in Bitcoin. That is a tiny volume comparing to popular payment networks. If Bitcoin adoption will continue at a good rate, it will not be long untill we will need to scale to something like 10 TPS.

computational problem
Verification is the most difficult function of nodes. Every input of every transaction has to be matched with an output of a previous transaction. We need to look up that previous transaction in a database of unspent transactions. If the UTXO DB does not fit in RAM, lookups involve disk I/O, which are relatively slow. With time, both transaction volume and UTXO DB grow. Nodes will have to verify more transactions and every verification will be taking more time on average.

The main difficulty with this all is synchronization. If a node goes offline for some time, it will have to catch up. At 10 TPS, 28 hours offline results in a backlog of 1 million transactions. If you think that it's not much, consider that UTXO DB will be much larger than it is now and an average transaction will take more time to verify than it does now. During that time a big share of the computer resources and maybe downstream network bandwidth will be occupied by Bitcoin.

Initial synchronization in its current form will be just infeasible for most users. Nodes will have to start in SPV mode and download and verify the full transaction history in the background. Again, eating some share of computer resources.


Title: Re: Size of BTC blockchain centuries from now...
Post by: DeathAndTaxes on July 12, 2013, 11:17:28 PM
Verification is the most difficult function of nodes. Every input of every transaction has to be matched with an output of a previous transaction. We need to look up that previous transaction in a database of unspent transactions. If the UTXO DB does not fit in RAM, lookups involve disk I/O, which are relatively slow. With time, both transaction volume and UTXO DB grow. Nodes will have to verify more transactions and every verification will be taking more time on average.

Well the good news is the UXTO grows much slower.  For example in the last 6 months the full blockchain has nearly doubled however the UXTO has grown from ~200MB to 250MB.  This is due to the fact that currency is eventually reused.  New transactions require older transactions to be spent.  The one exception is "dust" where the economical value of the transaction is less than the cost to spend it.  The ~250MB UXTO is about one quarter dust and most of that will never be spent.  If it is eventually spent it is only due to luck and time where the exchange rate rises enough that the dust isn't dust.  This is why the changes to 0.8.2 are so important.  By preventing worthless dust it limits the amount of the UXTO which isn't spent.  If the majority of the UXTO is regularly spent the size will grow even slower.  The size of the UXTO is more related to the number of unique users (with full control over their private keys) then the number of transactions.

Also the method of caching the UXTO is relatively inefficient right now.  The entire transactions is stored however if the inputs are already verified (which they are) then the UXTO could simply contain the already verified output only and possibly the full transaction hash for lookup against the full db.  Outputs are much smaller than inputs with average output size being 34 bytes and the average input size being 72 bytes.  This would indicate a roughly 66% reduction in UXTO is possible.  The vast majority of outputs are "standard" (OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG) for the purposes of the UXTO they could be simplified to a ledger like this:

TxHash - 32 bytes
OutIndex - 2 bytes
Amount - 8 bytes    
PubKeyHash - 20 bytes
Total: 62 bytes

Current UXTO has ~1.1 million unspent output so we are talking data (before db/disk overhead) being ~68 MB.   Obviously this isn't a pressing concern but given the UXTO grows relatively linearly, available memory grows exponentially and the current UXTO can be reduced to ~68MB the risk of UXTO spilling out of available memory and slowing tx validation is minimal.  The one threat was dust.  Since dust is almost never spent it causes the UXTO to grow much faster (they dust just keeps accumulating rather than cycling in and out of the UXTO).  With 0.8.2 that threat is removed.

This is a significant refactoring so don't expect it to appear anytime soon.  Eventually I think you will see the blockchain stored in three different formats.

1) The full chain.  Nodes keeping the full chain (containing all spent tx back to genesis block) will be archive nodes.  It isn't important for every node or even most nodes to be archive nodes but we would want a robust number to keep this archival copy of the blockchain decentralized.

2) The pruned chain & memory pool.  Most nodes will likely only retain the pruned blockchain, replacing spent tx with placeholders in the blockchain.  The memory pool contains the set of unconfirmed transactions.

3) In memory UXTO ledger.  Nodes will build this from the pruned database.  Since tx are already validated (or the tx and/or block would be rejected) it isn't necessary for the entire tx to be stored in the UXTO just the output portion.  Obviously you can't "only" have the UXTO or get the output only portion from other nodes as it can't be independently validated but this doesn't mean nodes can't build their OWN output only ledger from the pruned database.

As for CPU being a limitation I don't see that anytime soon.  A single 2.0 Ghz i7 core can perform 4,300 256 bit ECDSA signature validations per second.  Now that is just the ECDSA portion but it is the bulk of the computing needed to validate a transaction  Lets assume bitcoin implementation is no worse than half as fast and the average tx has two inputs that is a minimum of 2150 tps.  I would caution that this is probably a massive understatement of what is possible and assumes only one core is in use but use it as a worst case scenario.  To catch up 1 million transaction validation (roughly 28 hours of down time @ 10 tps) would take about 8 minutes to sync.  Remember this is just CPU "bottleneck" (or lack thereof).  For historical usage we can assume @ 10tps the first x years is a rounding error (blockchain today has ~3 million transactions or about 3 days at maxed out 10 tps).  To bootstrap from nothing the a node could validate (remember just CPU bottleneck so assuming network and disk and keep up) 185 million transactions per day or about 215 days at 10 tps.  So for near future the CPU isn't really a bottleneck.

Now at 1,000 tps it is a different story so this is why IMHO the first increase to block limit should be a single manual upgrade (to say 5MB or 10MB) to provide time to come up with more robust handling of high transaction volumes.  Those who wish to jump to an unlimited blockchain size are underestimating the risk of either through negligence or malice the blockchain growing so fast that while existing nodes can "keep up" it kills off the ability for new nodes to bootstrap. Given today we are only 0.4 tps I just don't see the potential risks of going from 1MB to unlimited overnight.  A modest one time increase (when necessary) would provide "breathing room" to come up with a more comprehensive solution.


Title: Re: Size of BTC blockchain centuries from now...
Post by: Yurock on July 12, 2013, 11:33:50 PM
It's good to know that problems have solutions. Hopefully, Bitcoin software will keep up with ever increasing load.