Topic: Would faster block creation give lower security? (Read 3136 times)

I think in face-to-face transaction situations, it's pretty safe. If it's not, then a 1 minute block time would be a bigger advantage.

It essentially gives higher resolution security, providing the all important first confirmation sooner.

There would be 4 times as many blocks, but if those blocks are 1/4 the size then the blockchain wouldn't be much larger (except for the overhead of the block headers)

I thought the bigger issue was it takes a certain amount of time for new blocks to flood the entire network, so a shorter target time would result in more side chains, wasting mining capacity, and requiring you wait for a higher number of confirmations for the same confidence, partially negating any benefits of shorter mining times?

Satoshidice has done such analysis, looking at fees paid, etc, and you can see their conclusion - how zero confirmation transactions are no longer automatically paid for just about anything.

Is there possible in some way to do any network analysis that can tell how 'good' a zero confirm is, e.g. how many nodes that has time stamped it or something, so that one could develop a scal between 0 and first confirm?

To conclude if your doing transactions as a merchant face-to-face with zero confirmation times... your going to have a bad time

I think I've read through most of the threads on the subject of reducing the block target time and most of them conclude that zero-confirmation transactions are the preferable way to do most in-person point of sale transactions, and that for most online transactions, waiting 1-6 confirmations is not a hindrance to commerce, as it takes at least one hour to ship a good any way.

What's been neglected is the minority case of online payments where a physical good is not shipped, like online casinos, or depositing bitcoin at an exchange. Any online wallet that accepts bitcoin deposits that can later be withdrawn will need to wait at least one confirmation before crediting the bitcoin to an account or else a double spend attack becomes extremely attractive for attackers and dangerous for the wallet operator.

Faster confirmations (e.g. 1 minute) would mean commerce would be much faster in these use-cases, like allowing deposits at exchanges to be registered in 6 minutes (or if the business wants to especially careful, 10 minutes). This would create a bitcoin economy that reacts more quickly to changes in demand, which I think would help reduce volatility by dampening the magnitude of bubbles, since potential sellers could move their bitcoin to exchanges and sell them more quickly when they see an unsustainable price increase.


Analysis definitely needs to be done, but I think it should be done in the event that bitcoin changes to a 1 minute block time. The next step I think is to see if there is significant support in the bitcoin community for exploring the option, and if so, creating a bitcoin testnet with 1 minute blocks and see how it behaves.

might be more accurate to say 99% (with networking latency propagation and all) but i got your point though

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.

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.

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.

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.

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.

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.

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.

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

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

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.

According to DeepCeleron:


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.

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

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?