Will the size of the blockchain file continue to increase indefinitely?

[bitbadger]

If Im understanding this correctly, each bitcoin transaction gets added to the blockchain file.

If so, then doesn't this mean that  the size of the blockchain file will continue to increase indefinitely?

Or is there some kind of limit, eg by time, or number of transactions or something?

Otherwise the blockchain would just get bigger and bigger...

It's already at 1GB.

[drawingthesun]

If Im understanding this correctly, each bitcoin transaction gets added to the blockchain file.

If so, then doesn't this mean that  the size of the blockchain file will continue to increase indefinitely?

Or is there some kind of limit, eg by time, or number of transactions or something?

Otherwise the blockchain would just get bigger and bigger...

It's already at 1GB.

At the most simple level, yes the blockchain will continue to increase. Satoshi considered this a worthwhile trade considering the benefits of the blockchain and the fact storage space has been increasing faster than the blockchain is growing.

There are things they could be done, I have heard of terms such as pruning and people talk of the older transactions being reduced to the absolute bare minimum needed for a valid chain.

The last time this thread came up someone with a high post count said something along the lines of this: 1GB could be compressed into 20MB, in which case its really not a issue at all.

Also if someone figures out a way to create distributed nodes where hundreds of computers share a blockchain this will also help minimize the size for hundreds of years time.

[Realpra]

Someone also suggested a ledger solution where transactions older than say 5 years would be removed and added to a ledger.

So say you have 1BTC going from A-->B-->C-->D-->E-->F where A is older than 5 years.

A yearly ledger would simply state that B had 1 BTC and remove A and all older roots as well.

The "ledger-block" would become part of the protocol and part of the chain as the first "link". It would simply behave much like a coinbase transaction.


If someone didn't trust this security level they could simply stay with the old client as there would be no protocol breach here. Ledger clients would simply be unresponsive when polled for blocks older than 5 years.
They could also move their funds every 4 years to be sure, but even if they didn't it would still be there even after 100 years.


This would definitely be a nice easy first step for Bitcoin scalability with distributed/swarm/collaborative nodes coming next.

[r.willis]

"Ultimate blockchain compression" is better solution than ledger block.

[mp420]

"Ultimate blockchain compression" is better solution than ledger block.

Yes, if by this you mean the solution proposed in this thread.

It's a monster to implement but the idea is solid.

[DannyHamilton]

- snip -
It's already at 1GB.
- snip -

Actually, I think it is already over 6 GB.

[Realpra]

"Ultimate blockchain compression" is better solution than ledger block.

I must disagree from what I read in the thread linked below your post it sounds like a lightweight client scheme. The full clients would still need the full chain so as the real Bitcoin network is concerned nothing is solved.

A coinbase ledger block however is simple, easy, secure and puts a finite limit to the blockchain size. As long as the limit is finite it doesn't really matter if you need one or two gigs extra compared to other esoteric solutions with mining and 2nd meta trees.

[spartacusrex]

We also had a pop at a solution here

https://bitcointalk.org/index.php?topic=152219.0

[r.willis]

I must disagree from what I read in the thread linked below your post it sounds like a lightweight client scheme. The full clients would still need the full chain so as the real Bitcoin network is concerned nothing is solved.

UBC is actually ledger block attached to every n-th normal block with added benefit of serving light clients a verifiable queries.
Without it, it actually boils down to replacing part of chain with UTXO set. How you make sure you got it right is another thing - trust miners (hash in coinbase transaction), trust developers (hardcoded into client) or trust network (ask maximum number of peers).

[bitbadger]

- snip -
It's already at 1GB.
- snip -

Actually, I think it is already over 6 GB.

I think you're right. At least that's how much space has gone from my hdd since I started downloading it.

[DannyHamilton]

- snip -
It's already at 1GB.
- snip -

Actually, I think it is already over 6 GB.

I think you're right. At least that's how much space has gone from my hdd since I started downloading it.

Assuming the maximum blocksize isn't increased, I'd assume that we should get to the point before long where the blockchain is growing by 4.3 GB per month (52 GB per year).  In that case it will take about 19 years to fill a 1 TB drive.

If the maximum blocksize is increased, then obviously the blockchain will grow quicker.

[torusJKL]

- snip -
It's already at 1GB.
- snip -

Actually, I think it is already over 6 GB.

Yes it is:
http://blockchain.info/charts/blocks-size

[TierNolan]

Ledger clients would simply be unresponsive when polled for blocks older than 5 years.

That is pretty much a breech.  That would prevent old clients from accepting the chain at all.

I assume the ledger clients would still keep the headers back to the root?

"Ultimate blockchain compression" is better solution than ledger block.

I must disagree from what I read in the thread linked below your post it sounds like a lightweight client scheme. The full clients would still need the full chain so as the real Bitcoin network is concerned nothing is solved.

If it is solid enough, then everyone could use it.

Basically the root of the transaction output tree is stored for every block.

It is possible to compute the new root if you have
- the old root
- the unordered set of spent transaction outputs in the block
- merkle branches relating to the spent transactions
- the unordered set of new outputs in the block

You get proof that
- the total number of coins is correct (new = old + minted)
- all spent transactions were in the valid transaction output set

Therefore without knowing the entire history you can verify the current block.

There is meta data required.  However, some of it would be the responsibility of the spender.  To spend a coin you need the merkle path for the block it was created.  This could be stored by the coin owner.

You also need the path for when it is spent.  This would change every block, so not sure how best to handle that.  Only the changing part is required though.  This is the part near the root where loads of paths converge.

[Stampbit]

The solution is actually pretty simple, if we just have one node print out the blockchain on a dot matrix printer, the paper should stretch to the house of the next node and so on.