Why not 10 coins per block and a block every 2 minutes?

[Bobnova]

As the title suggests, it seems to me like fewer coins per block but more blocks would be a plus.
Transactions would be confirmed faster, blocks would be confirmed faster, everything would go faster.
Seems like that would help bitcoin move into common usage.

[1713557980]

1713557980

[1713557980]

1713557980

[1713557980]

1713557980

[martin]

I believe blocks are spread in time to ensure that any messages will propagate across the entire network in the duration of a block, 10 minutes being a rather pessimistic view of how long it could take for a message to propagate.

The thing is, faster blocks would take less effort to generate, so to get the same level of security as you currently get by waiting 30 mins for three blocks, you'd have to wait 30 mins for 15 blocks. So, nothing would go faster, you'd just be consuming more traffic spamming the network with more blocks.

[error]

This question was answered in the FAQ. However the answer could probably use a bit of expansion. Feel free to work on it.

[ctoon6]

I think the positives outweigh the problems, but 2 minutes is too fast, id go for like 5 minutes. and me as a very very small merchant, i would still accept 2 confirmations. but if you want to sell anything big you will wait for the full 120 confirmations anyway, or if this happened 240.

[ctoon6]

most of the size comes from the transaction data. there would be less transactions in each block if blocks happened more often. but there is still overhead from there just being a block that was created. so i would guess it would only be like 1.5-1.8x more, not a full 2x

[Stephen Gornick]

I think the positives outweigh the problems, but 2 minutes is too fast, id go for like 5 minutes. and me as a very very small merchant, i would still accept 2 confirmations.

It comes down to ... is it instantaneous (i.e., a few seconds) or is it longer.   When longer, it doesn't matter if it is 45 seconds, two minutes or ten minutes -- they all don't pass as being "instantaneous".

There has been the argument that for most real world point of sale transactions, the risk to accepting at 0/unconfirmed even would not be high enough to deter a retail merchant from using bitcoin.  The risk can be cut even further with additional software that monitors for double spends attempts so that race attacks taking advantage of network speed would not be successful:
 - http://forum.bitcoin.org/index.php?topic=27417.msg350531#msg350531

If even having a low-risk of loss isn't acceptable, then there can be extensions that will help bridge how bitcoin works with how existing commerce works.  For instance, the Mt. Gox redeemable code can be used to transfer with immediate settlement bitcoins from one Mt. Gox account to another.  A mobile app for accommodating both sides of that is described here: http://forum.bitcoin.org/index.php?topic=25307.0

Of course, those transactions don't benefit from the advantages bitcoin offers, including pseudonymity (as Mt. Gox knows both parties), but since those transactions use bitcoins at least there needn't be a conversion to USD or other currency for them to be used in a retail transaction. 

(incidentally, the Mt. Gox redeemable code / voucher can be for either BTC or USD currencies.)

[ctoon6]

It comes down to ... is it instantaneous (i.e., a few seconds) or is it longer.   When longer, it doesn't matter if it is 45 seconds, two minutes or ten minutes -- they all don't pass as being "instantaneous".

There has been the argument that for most real world point of sale transactions, the risk to accepting at 0/unconfirmed even would not be high enough to deter a retail merchant from using bitcoin.  The risk can be cut even further with additional software that monitors for double spends attempts so that race attacks taking advantage of network speed would not be successful:
 - http://forum.bitcoin.org/index.php?topic=27417.msg350531#msg350531

If even having a low-risk of loss isn't acceptable, then there can be extensions that will help bridge how bitcoin works with how existing commerce works.  For instance, the Mt. Gox redeemable code can be used to transfer with immediate settlement bitcoins from one Mt. Gox account to another.  A mobile app for accommodating both sides of that is described here: http://forum.bitcoin.org/index.php?topic=25307.0

Of course, those transactions don't benefit from the advantages bitcoin offers, including pseudonymity (as Mt. Gox knows both parties), but since those transactions use bitcoins at least there needn't be a conversion to USD or other currency for them to be used in a retail transaction. 

(incidentally, the Mt. Gox redeemable code / voucher can be for either BTC or USD currencies.)

I know that this will in all likelihood will never happen. but i like the idea better where you just keep a tab or account at each restaurant you go to. an opensource app could be developed that could be run on a simple webserver that would handle the basic needs of a fast food place like McDonalds. amounts like 20$ or 1BC as of now would be safe to use after only 1 or 2 confirmations. so you could order your food on a smartphone or just add money to your account before you go, then once you arrive you tell them some information about your account or use a card or something and they make your food or you order it.

Another situation, a mall
you go to the mall and at the entrance is a bitcoin terminal. you put coins in the terminal and it shoots out a cheap card that can be recycled. by the time you walk to the first store yo buy somthing 10 minutes would have passed and you could have your merchandise. when you leave you put your card in and it releases any unspent coins.

With these ideas, bitcoin would still be decentralized, or more so than if we just all dumped our money into 1 company, which i do not think the good solution is.

[kjj]

I know that this will in all likelihood will never happen. but i like the idea better where you just keep a tab or account at each restaurant you go to. an opensource app could be developed that could be run on a simple webserver that would handle the basic needs of a fast food place like McDonalds. amounts like 20$ or 1BC as of now would be safe to use after only 1 or 2 confirmations. so you could order your food on a smartphone or just add money to your account before you go, then once you arrive you tell them some information about your account or use a card or something and they make your food or you order it.

Another situation, a mall
you go to the mall and at the entrance is a bitcoin terminal. you put coins in the terminal and it shoots out a cheap card that can be recycled. by the time you walk to the first store yo buy somthing 10 minutes would have passed and you could have your merchandise. when you leave you put your card in and it releases any unspent coins.

With these ideas, bitcoin would still be decentralized, or more so than if we just all dumped our money into 1 company, which i do not think the good solution is.

Some day, I expect to see VISA and MasterCard as the big players in these systems.  It will be easier for users to only have to track a few services like that, rather than one for each store/chain/mall.  But at least with Bitcoin, everyone has the choice, and since the software for it should be dead simple, choices will be abundant.

[ttk2]

As the title suggests, it seems to me like fewer coins per block but more blocks would be a plus.
Transactions would be confirmed faster, blocks would be confirmed faster, everything would go faster.
Seems like that would help bitcoin move into common usage.

You cant have blocks generating that fast, it would split the block chain. 10 minutes is the worst case propagation time for data in a distributed network. Every miner needs the last block to mine the next one, so if the time was lets say 30 seconds a block then two miners would find different solutions to the same block and then everyone near those miners would accept the new block and make new blocks based on it, this would mean that the block chain would split very often, leaving the transactions in those blocks lost and reversed. Currently two miners can find a block at the same time, but 10 minutes is enough for the network to chose one instead of making two separate chains.


Really transactions themselves are instant, broadcast through the network, confirmations are only required if your worried about double spending, if you see the transaction in your client, even if you have no confirmations you know that the transaction is valid unless someone has 51%, if you really think someone is going to pull a 51% attack for a sandwich you can wait a few minutes. 

[teknohog]

Don't forget that 10 minutes is the targeted average between blocks. Because the process is essentially random, you sometimes find less than 1 min between them, and sometimes closer to an hour. With a 10-minute average, the chances of getting two blocks too close together is low, but not impossible.

In addition, hashing power keeps increasing (albeit slowly these days), so even the average is less than 10 minutes.

[CydeWeys]

The short answer is that the percentage of wasted computational time increases exponentially as the average block finding time decreases.  This is particularly not good for miners.

The reason computational power is wasted is because a new block is not sent to the entire network instantaneously; it goes out to some nodes, who send it out to more nodes, etc., and eventually hopefully the entire network gets it.  Until the entire network does get it, there are still lots of miners wasting time wasting computations on blocks that will no longer be the longest chain and will thus be invalid.  Ten minutes seems to be a good trade-off between computational waste and speed of getting that first confirmation on a transaction.

Note that expressing the certainty of a transaction is based on computing time, however, not raw number of blocks.  When we currently wait for six blocks before saying a transaction is confirmed, what we really mean is that we're waiting for one hour (on average).  With two minute blocks we'd wait for 30 blocks before saying a transaction is confirmed, because 6 blocks times 2 minutes each is only 12 minutes, which simply isn't long enough to wait (it's not "enough" computing power and would be reversible a lot more easily than a whole hour's worth of computation would be).

[ctoon6]

The short answer is that the percentage of wasted computational time increases exponentially as the average block finding time decreases.  This is particularly not good for miners.

The reason computational power is wasted is because a new block is not sent to the entire network instantaneously; it goes out to some nodes, who send it out to more nodes, etc., and eventually hopefully the entire network gets it.  Until the entire network does get it, there are still lots of miners wasting time wasting computations on blocks that will no longer be the longest chain and will thus be invalid.  Ten minutes seems to be a good trade-off between computational waste and speed of getting that first confirmation on a transaction.

Note that expressing the certainty of a transaction is based on computing time, however, not raw number of blocks.  When we currently wait for six blocks before saying a transaction is confirmed, what we really mean is that we're waiting for one hour (on average).  With two minute blocks we'd wait for 30 blocks before saying a transaction is confirmed, because 6 blocks times 2 minutes each is only 12 minutes, which simply isn't long enough to wait (it's not "enough" computing power and would be reversible a lot more easily than a whole hour's worth of computation would be).

Solution:
cooperate with other miners and connect directly to each other. then you know as soon as a block comes out. and you would be surprised how fast information propagates in the network. i normaly never wait longer than 5 seconds to see a transaction, but i also have over 60 connections at any given time.

[kjj]

Solution:
cooperate with other miners and connect directly to each other. then you know as soon as a block comes out. and you would be surprised how fast information propagates in the network. i normaly never wait longer than 5 seconds to see a transaction, but i also have over 60 connections at any given time.

That is an excellent idea.  Perhaps we could even come up with some sort of relay system for the miners to use to automatically convey this information around so that we don't have to directly manage the connections ourselves.

[Bobnova]

The short answer is that the percentage of wasted computational time increases exponentially as the average block finding time decreases.  This is particularly not good for miners.

The reason computational power is wasted is because a new block is not sent to the entire network instantaneously; it goes out to some nodes, who send it out to more nodes, etc., and eventually hopefully the entire network gets it.  Until the entire network does get it, there are still lots of miners wasting time wasting computations on blocks that will no longer be the longest chain and will thus be invalid.  Ten minutes seems to be a good trade-off between computational waste and speed of getting that first confirmation on a transaction.

Note that expressing the certainty of a transaction is based on computing time, however, not raw number of blocks.  When we currently wait for six blocks before saying a transaction is confirmed, what we really mean is that we're waiting for one hour (on average).  With two minute blocks we'd wait for 30 blocks before saying a transaction is confirmed, because 6 blocks times 2 minutes each is only 12 minutes, which simply isn't long enough to wait (it's not "enough" computing power and would be reversible a lot more easily than a whole hour's worth of computation would be).

That's the sort of answer I was looking for, thanks.

[ctoon6]

I propose a theory

This theory will explain and confirm a few things

This theory has to do with the nature levels of security and the additional security granted at each level. for example, there is little or no security for a transaction just floating around in the network. however once the transaction makes it into a block, the amount of security granted is the greatest than any other jump. once block 2 as been generated, you don't have much additional security, so is it worth waiting for if you only have a small purchase.

[netrin]

I asked this same question today.

I haven't had my scribble calculations confirmed, but it seems to me that the weighted average latency between miners is 2.11 seconds. Miners waste 2 seconds hashing away the previous block every time a new block is awarded as well as waste at least an entire block if they happen to be on the loosing end of forked block chain (~0.5% chance every ten min block). The chance of forks is directly related to latency/generation-rate.

The latency is the same no matter the block generation rate. If you double the rate, waste should be halved (and then a little). I estimate that the system is entirely broken with a generation rate less than 5 seconds. If the rate were every minute the waste might be around 15%. Ten minutes puts us in the ballpark of 99% efficiency.

[ctoon6]

I asked this same question today.

I haven't had my scribble calculations confirmed, but it seems to me that the weighted average latency between miners is 2.11 seconds. Miners waste 2 seconds hashing away the previous block every time a new block is awarded as well as waste at least an entire block if they happen to be on the loosing end of forked block chain (~0.5% chance every ten min block). The chance of forks is directly related to latency/generation-rate.

The latency is the same no matter the block generation rate. If you double the rate, waste should be halved (and then a little). I estimate that the system is entirely broken with a generation rate less than 5 seconds. If the rate were every minute the waste might be around 15%. Ten minutes puts us in the ballpark of 99% efficiency.

I did more research, and what i proposed before was actually being worked on by bitcoin labs. with that, the network as we see it now could completely propagate in around 3 hops. thats less than 20 seconds on average.

[iopq]

I believe blocks are spread in time to ensure that any messages will propagate across the entire network in the duration of a block, 10 minutes being a rather pessimistic view of how long it could take for a message to propagate.

The thing is, faster blocks would take less effort to generate, so to get the same level of security as you currently get by waiting 30 mins for three blocks, you'd have to wait 30 mins for 15 blocks. So, nothing would go faster, you'd just be consuming more traffic spamming the network with more blocks.

not quite true, because some merchants only wait for one confirmation to credit you with the money

[netrin]

The thing is, faster blocks would take less effort to generate, so to get the same level of security as you currently get by waiting 30 mins for three blocks, you'd have to wait 30 mins for 15 blocks. So, nothing would go faster, you'd just be consuming more traffic spamming the network with more blocks.

While it is true that faster blocks would require a lower difficulty, the constant latency means that the wasted effort grows with block speed. If you can cut latency 50% across all nodes then you can cut block speed 50% with insignificant loss of efficiency (this excludes memory and bandwidth requirements which will obviously increase).

not quite true, because some merchants only wait for one confirmation to credit you with the money

But a faster confirmation will be more than proportionally less robust. With a doubled block speed competing forked block chain rates will more than double. As an extreme example, if the block speed were a few seconds (about the same as latency), then the network would thrash with the majority of 'confirmation' blocks being invalid. Less than a minute and the miners will spend twice as much energy producing the same number of hashes (with maybe 15% of all 'confirmations' invalid).

Miners could (and probably should) make direct connections to each other. However such a protocol requirement would make the network less robust. Indeed malicious miners would simply isolate the honest nodes.

[the founder]

Instead of screwing around with bitcoin's framework...  it's easier to just do transfers from ewallet to ewallet and it's instant that way...