More blocks/hour please

[newMeat1]

I'm sure this idea has been tossed around before, but I think it would be really great. How about a small block every, say, 10 seconds? Then you don't have to wait an hour to get a transaction confirmed 6 times. You would only have to wait a minute.

Are they any serious reasons why this can't be implemented? The only 2 I can think of are:

1. Block chain history gets too big, becoming a memory issue.

If so, we could start "forgetting about" the older end of the block chain. From what I understand, this would cause unused coins to be deleted. Well, that would be an interesting dynamic! Encouraging people to spend instead of holding for years and years.

2. Bandwidth limitations

[1715079665]

1715079665

[1715079665]

1715079665

[1715079665]

1715079665

[1715079665]

1715079665

[1715079665]

1715079665

[1715079665]

1715079665

[log0s]

Assuming the same total network hashing power, 6 confirmations with blocks every 10 seconds (1 minute) would be less secure than 1 confirmation with blocks every 10 minutes.  Assuming the bitcoin network suddenly switched to 1 block every 10 seconds, the difficulty, and therefore work required to create a new block would be much smaller, meaning an attacker could create a 6+ block fork far more easily.

The size wouldn't necessarily be as bad as it might seem originally as a higher number of blocks per unit of time would mean less transactions in each block.  The main size increase would be from an increased number of block headers.  The total bytes in block headers would go from 480 bytes to 28800 bytes.  Bandwidth wouldn't necessarily be a problem, either, but latency would be a HUGE problem.  Miners would constantly be creating forks in the blockchain as they would never be up to date on the blockchain due to the time it would take for a block to be broadcast across the entire network.  As more transactions are included in blocks, the worse this latency would get, since nodes need to verify the block and each transaction in the block before relaying it...if a block contains a lot of transactions, verification alone could easily take longer than 10 seconds.

[newMeat1]

Hmmm OK. So 10 seconds won't work. What about trimming that time down a little bit?

[techwtf]

solidcoin and other copy coins are now bitcoin's test net, they feature like 1.5 min / 3 min between blocks.

[tysat]

Hmmm OK. So 10 seconds won't work. What about trimming that time down a little bit?

The whole point of waiting for 6 confirmations is to wait for an hour's worth of blocks to be hashed out.  If you had 1 block a minute you'd want to wait for 60 confirmations.  6 confirmations isn't just some magical number that never changes based on the target block rate being shorter or longer.

[dree12]

Hmmm OK. So 10 seconds won't work. What about trimming that time down a little bit?

The whole point of waiting for 6 confirmations is to wait for an hour's worth of blocks to be hashed out.  If you had 1 block a minute you'd want to wait for 60 confirmations.  6 confirmations isn't just some magical number that never changes based on the target block rate being shorter or longer.

Not nessesarily, it could also be reducing the chance to double-spend by a major holder to unprofitable. For example, assume someone is trying to attack http://bitcoinlaundry.com/. Since they charge a 5% fee, any attempt to double-spend is unprofitable if the chance of getting 6 confirmations (I assume this is when the laundry sends the coins) in a row (or 7 blocks) falls below 5%. So in this case, bitcoinlaundry wouldn't care about how long or short blocks are (to a certain extent).

As satoshi detailed in his whitepaper, the issue is network latency. It takes around 3 seconds for a block to spread around the entire network, and this is only 0.5% of the 10-minute block time. Cancer node attack is possible if this percentage rises. In 10-second blocks, this is 30% of the block time, so the attacker can broadcast a tx and a confirming block(s) to a certain group of nodes, and not to others. A fork is now very likely in this time so long as the attacker only broadcasts his own blocks only to that certain group of nodes. Once the other blockchain catches up, the attacker could either have lost nothing but some cpu time or fees, or have pulled off a successful double spend.

Satoshi believed 10 minutes to be this magic number. There is no proof that this is the best number, and only one attack maybe due to short block times (the myBitcoin incident) has been reported, but that attack could possibly just as well be pulled off with a standard 2-blocks-in-a-row (deepbit or btcguild or slush, for example, certainly had the capability, even though evidence suggest it isn't them). It is likely that ten minutes is too long, but we still don't know if anything else is better.

[amincd]

=Since they charge a 5% fee, any attempt to double-spend is unprofitable if the chance of getting 6 confirmations (I assume this is when the laundry sends the coins) in a row (or 7 blocks) falls below 5%. So in this case, bitcoinlaundry wouldn't care about how long or short blocks are (to a certain extent).

Why wouldn't they care? How many blocks bitcoinlaundry would need to wait to get the odds of an attacker getting that many confirmations in a row, below 5%, would be proportional to how short/long the blocks are.

[dree12]

=Since they charge a 5% fee, any attempt to double-spend is unprofitable if the chance of getting 6 confirmations (I assume this is when the laundry sends the coins) in a row (or 7 blocks) falls below 5%. So in this case, bitcoinlaundry wouldn't care about how long or short blocks are (to a certain extent).

Why wouldn't they care? How many blocks bitcoinlaundry would need to wait to get the odds of an attacker getting that many confirmations in a row, below 5%, would be proportional to how short/long the blocks are.

No no, you see. The chance of double-spending this way REQUIRES the attacker to confirm invalid transactions! If more non-attacker blocks appeared than attacker blocks, the attack is now over. There is no reason to care about the block time if the attacker used that attack.

[Cosbycoin]

Good point. I wonder what will happen when the block history gets to like 10 terabytes. Then it will take forever to download it with current technology.

[bitcoinhead]

Would it be possible to trim the blockchain by periodically publishing a block with the status of all current bitcoins?  Then one could delete the history between these events?  Almost like a system checkpoint event.

Forever having to store the entire transaction history won't scale.  If that is what is needed, then eventually it seems like most people will need to use hosted wallets.

[vanDeGraph]

Would it be possible to trim the blockchain by periodically publishing a block with the status of all current bitcoins?  Then one could delete the history between these events?  Almost like a system checkpoint event.

Forever having to store the entire transaction history won't scale.  If that is what is needed, then eventually it seems like most people will need to use hosted wallets.

This is an interesting idea if we can make the checkpoints verifiable. The system right now is secure because the client can verify the entire block chain.

[BitcoinSEC]

I disagree