Would faster block creation give lower security?

[TierNolan]

I'm not sure if you get me, but "6 blocks" is an arbitrary number and probably only in bitcoin-qt because it equals 1 hour of blocks. It is in no way necessary or any indication that a transaction is neraly impossible to double spend. 6 blocks on a 1000TH/hour 1 minute block chain are far easier to double-spend than 2 blocks on a 1000TH/hour 10 minute block chain.

It is a tradeoff with 3 considerations;

From the original bitcoin paper.  If the hostile miner has 10% of the hashing power, then 5 blocks is enough so that there is a 0.1% chance of random reversal.

The price of hashes allows you to estimate the cost of overpowering the network.  You need to match the current hashing power for 6 blocks worth of time to brute force a double spend.

If network latency becomes significant, then miners who win a block get a big advantage in winning the next block.  If the block rate is fast enough that could give a miner with a small portion of the hash rate effectively more than 50%.  This breaks the incentive to broadcast blocks, which drives other miners out.

[amincd]

I'm not sure if you get me, but "6 blocks" is an arbitrary number and probably only in bitcoin-qt because it equals 1 hour of blocks.

Taking one hour is not the reason given in the bitcoin white paper for the choice of 6 blocks. Nakamoto explained that after a transaction is six blocks deep, a successful double spend by an attacker with 10% of the network hashrate would become extremely unlikely. Six blocks was a guess on what would provide a sufficient amount of security for most transactions.

6 blocks on a 1000TH/hour 1 minute block chain are far easier to double-spend than 2 blocks on a 1000TH/hour 10 minute block chain.

But it's not. An attacker has just as much of a chance of getting 6 blocks consecutively in a 1 minute block chain as in a 10 minute block chain.

. Then after e.g. 10 times your transaction amount was already spent on mining after the first confirmation, you consider the transaction finalized, as it would not make any economic sense to scam you that far down the chain.

The financial cost to attempt a double spend attack for a transaction with a given number of confirmations is greater in a 10 minute block chain than in a 1 minute blocks, this is true, but it's not the only thing to consider for security. There are other aspects of transaction security where faster block time provides an advantage.

Since any security disadvantages of a more quickly created block, except wasted work from latency, can be neutralized by simply waiting for more confirmations, faster block time on the whole can provide security advantages with no draw backs, assuming the wasted work from latency doesn't become excessive.

[jl2012]

There will be more orphaned blocks with faster block creation. As more hashing power is wasted, security is lowered

[doobadoo]

So the post-mortem:
-Miners were instantly klined from IRC, and can't bootstrap to get other clients to connect to,
-Difficulty 20000 worth of miners try to use a difficulty 1 network with about 1000 block finds every second
-miner -> pool latency is major fail and still can't keep up with new blocks every few seconds.

Conclusion
The p2p network becomes completely useless. The miner with the most hashrate on their local i0coind makes the longest blockchain independently. When there are finally enough connections and a high enough difficulty that everybody can start to get blocks from each other's blockchain forks, the longest blockchain wins - the person who could independently get 600 blocks ahead of everybody else by block 3500, and wipe out everybody else's balance when it was announced.

The few miners with the fastest local hashrate can keep on adding generate wins to their own blockchain. Because of continued network fail they can get two blocks or more ahead of everybody without hitting the network, and the slow network with dozens of blocks a second just keeps toasting everybody else's block finds that are a block too late in their block find announce.

this was only a fail b/c he started the difficulty way too low.   I remember GeistGeld experimented with a 2-3 second hash rate and had a stable chain...think it ran for months.  but then again maybe that network was only a handful of nodes so every one was connected and block propagation to all miners might have been under 1 sec.

Who was the dude who did GG, and where is he now?

[amincd]

^ Wasn't GeistGold a 15 second block time chain?

[doobadoo]

There will be more orphaned blocks with faster block creation. As more hashing power is wasted, security is lowered

yes, but shorter blocks would have few tx's in them, and would propagate faster.  Ur just talking about headers.  Unless clients move headers to the next client w/o verifying remaining sigs and building the merkle roots  (doubtful).

[doobadoo]

^ Wasn't GeistGold a 15 second block time chain?

yeah but at launch i think he reported the fucker was clocking a new block every 3-4 secs.

[doobadoo]

One way to look at it is there is a "critical window" that is the period of time between when a miner solves a block and when the entire network (of miners) knows of it and is using that block hash in the next block.  With 600 seconds EXPECTED TIME between blocks, for every 6 seconds in the "critical window" roughly 1% of hashpower will be lost due to orphans. 

If an average Bitcoin block is like 256k, how does it take 6 seconds to propagate.  Most people should be able to move that in under a second, and the sig verifications and hash verification/merkle root should be trivial if the client was testing and retaining sigs from the relay txns.

You might do 8 hops in that time, should be enough to reach vast majority of miners.   Or am I off on that?

[doobadoo]

...At average 6 blocks per hour, 1 in 100 blocks will be found currently in less than six seconds. Increase the block finding rate to average one a minute, and then you get 9.5 in 100 blocks that will be under six seconds.

Why is the distribution so volatile?  1 in 100 blocks is a two sided z-score of 2.5.  Assuming normal distribution, mean 600, -2.5z = 6sec implies a standard devation of ~240 seconds (4 minutes).    For shizzle?   Or maybe is some bizzare Poison calculation like i think is used for random chance calculations.  O me of my now i have to get out excel and do an empirical analysis of block generation and see what curve it is...

Edit: Wow last 20 blocks:
avg    470    sec
stdv    391    sec

[amincd]

There will be more orphaned blocks with faster block creation. As more hashing power is wasted, security is lowered

According to DeepCeleron:

At average 6 blocks per hour, 1 in 100 blocks will be found currently in less than six seconds. Increase the block finding rate to average one a minute, and then you get 9.5 in 100 blocks that will be under six seconds. If it takes six seconds for a block to propagate to all other nodes, that would give an attacker an advantage to build further on his own blocks, or for pool-size miners to increase their income by creating orphans when they promote their own late blocks over the network's best block.

If the critical window is six seconds, then 1% of the work would be wasted with 10 minute blocks, and 10% would be wasted with 1 minute blocks.

Therefore, with bitcoin's 63.58 TH/s hashrate, an attacker needs approximately 62.94 TH/s (99% of the rest of the network's hashrate) to perform a >50% attack with 10 minute blocks, while they would need approximately 57.22 TH/s (90% of the rest of the network hashrate) for a >50% attack with 1 minute blocks.

I don't think the decrease in the computational requirement of attacking a 1 minute block time blockchain with bitcoin's hashrate is significant.

[wingding]

Quite a lot of numbers to digest here! But what I understand is the key problem with a faster block rate is that honest nodes will spend more of their computing power building blocks that are wasted, hence giving the attacker an additional advantage, because she can use all the blocks she create.

[deepceleron]

Why is the distribution so volatile?  1 in 100 blocks is a two sided z-score of 2.5.  Assuming normal distribution, mean 600, -2.5z = 6sec implies a standard devation of ~240 seconds (4 minutes).

Block finding time is actually a binomial geometric distribution, since each hash attempt is a discrete Bernoulli trial, however, the probability is so low it can be viewed as continuous negative exponential distribution.
An exponential distribution has a standard deviation equal to the expectancy value. This predicts a 10 minute standard deviation for Bitcoin.

The density shows the high chance of short block times, with a very long tail:


What are the chances that a block will be found in less than 6.04 seconds:
>>> (1-1/math.exp(6.04/600.0))*100
1.0016167373020024 %

Here's as relevant a book as you will find to the kind of probability statistics used in Bitcoin:
http://vfu.bg/en/e-Learning/Math--Bertsekas_Tsitsiklis_Introduction_to_probability.pdf

[amincd]

Quite a lot of numbers to digest here! But what I understand is the key problem with a faster block rate is that honest nodes will spend more of their computing power building blocks that are wasted, hence giving the attacker an additional advantage, because she can use all the blocks she create.

From what I know about the relationship between security and block target time, that's exactly right.

[Xenland]

I haven't read many posts but i believe that this has been debated before that if you have faster block creation you need more confirmations to compensate for security, so basically you will always have to wait the same amount of time to get the current 6 blocks confirmation security, The only gain from increasing faster blocks is faster progress reporting of when your full security will be locked into place which is pointless almost.

[amincd]

This is not true. While some security is established by the amount of time required to get a confirmation, an attacker with a given hashrate will have a much higher probability of double spending a 1-confirmation transaction in a 10 minute block-time chain than a 10-confirmation transaction in a 1 minute block-time chain. Meni Rosenfeld showed this mathematically: https://bitcoil.co.il/Doublespend.pdf

The trade-off as far as I can see is that with a higher rate of block generation, latency wastes more work, leading to lower difficulty for a >50% attack. For a POW network with a 62.94 TH/s hashrate like bitcoin, a 10% decline in the difficulty of pulling off a >50% attack is probably tolerable, and worth the gain in more quickly secured transactions.

[Xenland]

This is not true. While some security is established by the amount of time required to get a confirmation, an attacker with a given hashrate will have a much higher probability of double spending a 1-confirmation transaction in a 10 minute block-time chain than a 10-confirmation transaction in a 1 minute block-time chain. Meni Rosenfeld showed this mathematically: https://bitcoil.co.il/Doublespend.pdf

The trade-off as far as I can see is that with a higher rate of block generation, latency wastes more work, leading to lower difficulty for a >50% attack. For a POW network with a 62.94 TH/s hashrate like bitcoin, a 10% decline in the difficulty of pulling off a >50% attack is probably tolerable, and worth the gain in more quickly secured transactions.

That all does sound inline with my knowledge as well but I think the conclusion in the debate as i remember it ended something like "its more profitable to mine the bitcoin blocks than it is to attempt a 51% attack as most retailers, casinos, and other big businesses won't allow you to run off with something until all 6 confirmations are confirmed which would be about the worth if not more than the hiest and if it isn't then that business is just ignorant and stupid for not waiting for all 6+ confirmations.

[TierNolan]

That all does sound inline with my knowledge as well but I think the conclusion in the debate as i remember it ended something like "its more profitable to mine the bitcoin blocks than it is to attempt a 51% attack as most retailers, casinos, and other big businesses won't allow you to run off with something until all 6 confirmations are confirmed which would be about the worth if not more than the hiest and if it isn't then that business is just ignorant and stupid for not waiting for all 6+ confirmations.

For large transactions, the client could update the "confirmed" code.  At least 6 blocks and ((average fee + mint reward) * number of blocks) > (value of transaction * some constant).

The cost of 1 block's worth of POW can be estimated as the average block payout.  This ensures that the cost to brute force a reversal (constant) times more than the transaction.

[deepceleron]

This is not true. While some security is established by the amount of time required to get a confirmation, an attacker with a given hashrate will have a much higher probability of double spending a 1-confirmation transaction in a 10 minute block-time chain than a 10-confirmation transaction in a 1 minute block-time chain. Meni Rosenfeld showed this mathematically: https://bitcoil.co.il/Doublespend.pdf

TL;DR:
"The probability of success depends on the number of blocks, and not on the time constant T0."

These statistics are in a network latency-free statistics environment. Multiscale Monte Carlo simulations would need to be performed to find where propagation times on fast-confirmation (or huge block size) networks detectably increase the number of blocks required for the same resistance against blockchain reorganization.

[astor]

This is not true. While some security is established by the amount of time required to get a confirmation, an attacker with a given hashrate will have a much higher probability of double spending a 1-confirmation transaction in a 10 minute block-time chain than a 10-confirmation transaction in a 1 minute block-time chain. Meni Rosenfeld showed this mathematically: https://bitcoil.co.il/Doublespend.pdf

TL;DR:
"The probability of success depends on the number of blocks, and not on the time constant T0."

These statistics are in a network latency-free statistics environment. Multiscale Monte Carlo simulations would need to be performed to find where propagation times on fast-confirmation (or huge block size) networks detectably increase the number of blocks required for the same resistance against blockchain reorganization.

This all assumes that the optimal strategy is full propagation.  I fear that miners today already have incentives to prohibit propagation in order to induce the exact same conditions that happen during fast block creation.

[TierNolan]

This all assumes that the optimal strategy is full propagation.  I fear that miners today already have incentives to prohibit propagation in order to induce the exact same conditions that happen during fast block creation.

The problem with holding back is that some other miners might get their block out before you can get yours.

In a low latency network where you have 10% of the network and have just found a block, you have 2 choices.

Hold it back

90% chance someone else hits another block and propagates it (payout 0)
10% chance you win it (payout 2X)

Average: 10% of 2X = 0.2X

Broadcast it

99% chance you win the block (payout 1X)

Average: 99% of 1X = 0.99X

So, broadcasting is optimal.

The problem with a high latency situation is that even if someone else hits the next block, they can't broadcast it fast enough.  The key is that when a new block is hit, you can trigger all the rest of the network to build on your block by broadcasting it.  If the block rate is to fast, then you don't get the benefit from broadcasting it.