Bitcoin Forum
December 07, 2016, 06:28:20 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: More blocks/hour please  (Read 776 times)
newMeat1
Full Member
***
Offline Offline

Activity: 210



View Profile
August 31, 2011, 01:49:22 AM
 #1

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

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
log0s
Jr. Member
*
Offline Offline

Activity: 43


View Profile
August 31, 2011, 02:23:59 AM
 #2

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
Full Member
***
Offline Offline

Activity: 210



View Profile
August 31, 2011, 02:47:40 AM
 #3

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

techwtf
Full Member
***
Offline Offline

Activity: 140


View Profile
August 31, 2011, 02:57:58 AM
 #4

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

Activity: 952


Keep it real


View Profile
August 31, 2011, 03:23:25 AM
 #5

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
Legendary
*
Offline Offline

Activity: 1232



View Profile
September 04, 2011, 01:40:02 AM
 #6

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
Hero Member
*****
Offline Offline

Activity: 772


View Profile
September 04, 2011, 01:49:13 AM
 #7

Quote from: drlee
=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
Legendary
*
Offline Offline

Activity: 1232



View Profile
September 04, 2011, 05:51:00 PM
 #8

Quote from: drlee
=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
Full Member
***
Offline Offline

Activity: 140


View Profile
September 12, 2011, 10:17:16 PM
 #9

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
Newbie
*
Offline Offline

Activity: 15


View Profile
September 12, 2011, 11:20:25 PM
 #10

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
Newbie
*
Offline Offline

Activity: 12



View Profile
September 12, 2011, 11:51:52 PM
 #11

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.

I got 99 problems but a bit ain't one
1JCk7WHmdmSTQaaRPHGDVuYTB5o1XRENav
BitcoinSEC
Jr. Member
*
Offline Offline

Activity: 34


View Profile
September 13, 2011, 12:11:39 AM
 #12

I disagree
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!