1
1
As I understand it, without implementing disk-space-reclamation as laid out in Satoshi's paper the system will not scale because the blockchain contains a history of every transaction. Bitcoin has been going a few years at below 1 tps and the blockchain is already over 6GB. At 4000 tps it will be unmanageable.
Again, as I understand it, you can only remove a transaction from the blockchain if both its outputs have been fed into new transactions, and they are buried deep enough in the blockchain.
If I were to split a single bitcoin into 100,000,000 smaller bitcoins and save them for eternity in my "piggy bank" wallets, would that force all miners to save at least that much data for eternity?
In fact, what about the case where a large number of people - without any malice - choose not to spend small amounts of money for a long time. Would this not also break disk space reclamation? Has this been modelled?
Thanks!
Remember: 1 block every 10 minutes, and max block size is (today) 1 MB. The blockchain can't grow more than that. The max block size will likely be raised at some point, but I still don't think the blocksize will ever be a "dangerous" problem. Only miners will need to run a full client and S.DICE is already "stress testing" the bitcoin network, so the problem can't really be much worse (and ~6GB in 4 years is almost nothing, imo). – Nicolai – 2013-04-02T20:47:59.883
I don't understand! Each block hashes the Merkle root of all (or at least most) of the transactions that have occurred since the last block. If a new block is created once every 10 mins and there are 4000 tps that's 2.4 million transactions per block. Assuming the transactions require (say) 100 bytes then that's a quarter of a gigabyte that must be stored somewhere, every 10 minutes. Why do you think the problem can't get much worse? I agree that 6GB in 4 years is almost nothing but we are at under 1 tps at the moment.... – Alex Zeffertt – 2013-04-03T10:45:55.067
The miner decides which transaction he will include in the block. If the miner include too many transactions (so block size > MAX_BLOCK_SIZE) then the block won't be accepted as a valid block. – Nicolai – 2013-04-03T11:22:31.737
Defining a MAX_BLOCK_SIZE only solves the problem limiting the transaction rate. If we want to fix the block rate at 1 block every 10 minutes, but scale to 4000 transactions per second, won't we need to increase MAX_BLOCK_SIZE to a huge value? My question is really: does the fact that all unspent transactions have to be saved for eternity introduce a weakness that will gradually make the system less effective and possibly open it up to attack? – Alex Zeffertt – 2013-04-03T14:20:37.967