Am I missing something, or is ledger growth going to rapidly become an issue?

[prodigy]

A glaring problem I've been thinking about lately, and I'm surprised I haven't seen any discussion on it, is the growing size of the block chain.

The transaction ledger grows each day, and because it's permanent, eventually it will get very computationally expensive to move a single coin because it has a huge transaction history built up on it.

Am I missing something here? To me it seems that over time the global block chain will grow in size to the point where it consumes all computing resources thrown at it. Home PC's can't be expected to store multi-gigabyte (or terabyte) block chains just to perform transactions.

Am I completely off-base here?

[CJYP]

Your computer doesn't have to download the entire block chain to run Bitcoin. It just has to download any transactions including the wallet.dat file it's associated with.
I might be wrong, though.

[SgtSpike]

I had the same question/concern not too long ago.

Basically, at some point, we'll see people move from using a normal client to using a chainless client.  The chainless or lite client would connect to one or more nodes to find and verify their account balances, etc.

Most of the code already exists to utilize a lite client.  It's just a matter of implementing the final pieces now.

[Harry]

The transaction ledger grows each day, and because it's permanent, eventually it will get very computationally expensive to move a single coin because it has a huge transaction history built up on it.

Am I missing something here? To me it seems that over time the global block chain will grow in size to the point where it consumes all computing resources thrown at it. Home PC's can't be expected to store multi-gigabyte (or terabyte) block chains just to perform transactions.

As far as I understand this, the complete block chain is only needed to be downloaded once if you start a BitCoin client. If you want to make a transaction, you only put this transaction request (size depends only on the contents of your transaction) in the system. The next block that is computed for the block chain will (hopefully) include your transaction. This is the first affirmation of your transaction. If six further blocks are created without any problems regarding your transaction, it is believed as valid.
To compute a new block, only the last created block is needed. The hash of the last block goes into the new one - confirming the last one.
The hole block chain is only needed to verify that the hole block chain is valid.

Right now, each new block is about 10 MB in size. That is every ten minutes.
Right now I have nearly 500 MB data for 132129 blocks - thats nearly 4 KB each. When there where no transactions, the blocks had a size of 216 Bytes.
So maybe you are right, if there are more transactions, the block size will increase. Resulting in maybe a few hundred MB per block in a few months if BitCoins grow further and is maybe accepted by Amazon
With an average of 144 blocks a day that would be more than 50 GB a day if the block size reaches 350 MB.
Hm, so maybe I should start to look for a faster internet connection.

That's what I understand this far.
Corrections welcome

[prodigy]

I had the same question/concern not too long ago.

Basically, at some point, we'll see people move from using a normal client to using a chainless client.  The chainless or lite client would connect to one or more nodes to find and verify their account balances, etc.

Most of the code already exists to utilize a lite client.  It's just a matter of implementing the final pieces now.

I assume that at this point main chain processing would be done by 'super-nodes' of some sort? It still seems like larger and larger data centers would be required to process millions of transactions quickly in the face of non-stop growth of the chain. I'm ignorant of the math behind it, but is there some way to trim or 'age out' ancient blocks without compromising the entire chain?

Think of the millions of transactions per day handled by MasterCard/Visa/Etc, on ecommerce sites like Amazon, eBay, etc. That would lead to exponential (i.e. block^2) growth over time and doesn't seem sustainable on a world-use scale.

[davout]

Transactions can be pruned under certain conditions, read satoshi's paper if you haven't already.

[compro01]

A glaring problem I've been thinking about lately, and I'm surprised I haven't seen any discussion on it, is the growing size of the block chain.

The transaction ledger grows each day, and because it's permanent, eventually it will get very computationally expensive to move a single coin because it has a huge transaction history built up on it.

Am I missing something here? To me it seems that over time the global block chain will grow in size to the point where it consumes all computing resources thrown at it. Home PC's can't be expected to store multi-gigabyte (or terabyte) block chains just to perform transactions.

Am I completely off-base here?

and hard drive space keeps growing too. 

9 years ago, i had a 120GB hard drive
now, i have 1250GB of hard drive space.

storing the block chain should not be a problem for the foreseeable future, though people are working on implementing block pruning and the headers-only client, which would drastically shrink the amount of data one would need simply to use bitcoin.

[NF6X]

I'm more concerned with the bandwidth requirement to catch up to the end of the block chain after a period of disuse, particularly for a portable client with poor connectivity compared to an urban/suburban fixed broadband connection. I live in a rural area with a cell modem as my only Internet connection, so I'm almost always in that situation. I started playing with Bitcoin very recently, and it took many hours for my client to get the full block chain over my cell modem. When I'm at work I don't have access to any open wifi networks, and I don't want to run P2P software over our corporate network (assuming the firewall would even allow it). So, I mostly just have cel network devices for my personal networking use except when I camp out at SBUX for a couple hours on weekends to catch up on larger downloads.

Granted, my lack of connectivity is unusual, but it makes me more sensitive to this kind of issue. I'm looking forward to the development of lightweight clients which are suitable for portable use without a fixed (or even very good) network connection while still being adequately secure and robust for day to day use in small transactions. I think it's safe to assume that a user of such a product is likely to be able to have a fixed machine with a better network connection for when that is needed (even though I don't have one), as well as an off-line wallet with most of their savings in order to limit their risk if their portable device is lost or compromised.

[unmitigated]

Actually that very fact is part of the genius of bitcoin.  You see, transactions will themselves become progressively more difficult because of the coins involved and how often they are moved around (mirroring the artificial increase in difficulty for miners now).  Because whoever's left over will already have hardware literally tailor-built to handle this type of transaction, the infrastructure will exist long before it's needed, and well in excess of day-to-day transaction requirements.  This is precisely why mining won't "only" be profitable until all 21M bitcoins are minted, as we progress the transaction fees to push someone ahead in line will be worthwhile for miners as well.

[grau]

Most of the code already exists to utilize a lite client.  It's just a matter of implementing the final pieces now.

A chainless "lite" client would have to trust other nodes to verify a coin, and this would be contrary to design principles of bitcoin.

[NF6X]

A chainless "lite" client would have to trust other nodes to verify a coin, and this would be contrary to design principles of bitcoin.

True, but is there a better alternative for a portable device with a slow, unreliable or expensive connection (such as a smart phone, possibly roaming in a foreign country)? There are plenty of situations where a person may wish to be able to spend some currency, but not have the ability to maintain a stable connection to a P2P network. For Bitcoin to succeed as a general purpose currency, I think there will be a need to address such use cases, even if they're limited to infrequent cases where a user might accept elevated risk while spending a small amount of "pocket change".

[TerraHertz]

Wait, what? A virtual monetary system in which the data volume that must be processed to maintain system functionality grows perpetually?

Seriously?

I'm new here, so I expect I'm missing some stupid detail which shows it isn't so. Hopefully. Because otherwise the entire scheme is insane.

[JoelKatz]

You always have to 'trust' other nodes (so long as it is significantly more work for them to fool you than it would be worth). When you fire up the client for the first time, you get the chain from other nodes. Theoretically, a group of conspiring evil nodes could send you an entire false chain.

A lite client that polled a randomly selected set of other nodes just to get the last block for any given bitcoins it had to handle would be reasonable, in my opinion. You could check forward and back a few blocks if desired, which would significantly increase the work needed to fool the lite client as a large chunk of chain, proof of work and all, would need to be faked. It might not be the best idea for large transactions, but for small ones, it would cost way more resources to trick it than to mine the same amount.

[prodigy]

Wait, what? A virtual monetary system in which the data volume that must be processed to maintain system functionality grows perpetually?

Seriously?

I'm new here, so I expect I'm missing some stupid detail which shows it isn't so. Hopefully. Because otherwise the entire scheme is insane.

I'm kind of thinking the same thing. Even with the possibility of 'lite' or 'chain-less' clients, the exponential growth of data required just to sustain day-to-day transactions seems infeasible.

Unmitigated commented that the increasing difficulty is part of the genius of Bitcoin, but I have to disagree. It may be effective at creating a predictable rate of money creation, but once all Bitcoins have been generated and (in the ideal scenario) the whole world is using Bitcoins for day-to-day transactions, it becomes a serious problem, since the space required to store the entire chain grows without bounds. Say for example you wanted to move a single coin that has already been moved 3,500,000 times. That's a pretty significant chain to verify, even for a large GPU-based data center!

TL;DR: There may be something I don't understand, but it seems like block/chain growth in size and difficulty will eat up all computing resources thrown at it (I'm thinking years down the road when all coins have been generated).

Edit: idea clarification

[bitcola]

Why are the old blocks needed?

They should be set to expire after some time or no. of transactions surpassed.

Someone somewhere will have backed them up. There could even be several independent servers around the world that can give the 6 confirmations or whatever.

There'll have to be an incentive to set one up though.

[prodigy]

Why are the old blocks needed?

I think they're required to verify the entire chain from the beginning (the Genesis block). I.e. trace back the entire transaction history for the whole network and prove no coins have been double-spent.

[SgtSpike]

Most of the code already exists to utilize a lite client.  It's just a matter of implementing the final pieces now.

A chainless "lite" client would have to trust other nodes to verify a coin, and this would be contrary to design principles of bitcoin.

You already trust 8 other nodes that they are sending you the proper block chain, what would be the difference in changing that to trusting 8 nodes that they are handing you your proper account balance and information?  And if you didn't want to rely on that, you could always continue storing the blockchain on your own computer.  It'll get large, sure, but that's the price you pay if you don't want to trust other nodes.

I think the biggest issue to figure out is how the nodes that keep the block chain will be paid for keeping the block chain and answering queries about it.  Obviously, pools have their fees, and will have to maintain the blockchain in order to hand out work to pool miners, but they could potentially just refuse a lite client's request to get information about a given list of addresses.  After all, if most people are reliant upon a few dozen nodes total, then there could be a LOT of data transfer and computational power needed to answer as many requests/second as would inevitably be generated.