Would faster block creation give lower security?

[wingding]

First, let me state how I understand the hashcash system and difficulty in block creation: The difficulty is adjusted to maintain a steady supply of block per unit time. The reward per block, i.e. new bitcoin created, is set to reduce exponentially with number of blocks, hence exponential decrease of money supply with time. For a transaction, each confirmation is actually a new block creation containg over the block that contain your transaction (?)

 So then I wonder:
If difficulty was fixed, say to current level. Then with more miners and better equipment coming in as function of time, block creation would go faster. Would a faster creation of blocks represent a security issue for the chain integrity? (I do of course understand it would increase the speed of new coins created)

I ask of this for two reasons: First of all, faster block creation would giver faster confirmations. Secondly I believe that fixed difficulty and increased money supply would make a better system. The value of new money would be closely related to energy.

[1715631230]

1715631230

[1715631230]

1715631230

[1715631230]

1715631230

[mgio]

Yes, it would be a huge security risk as eventually it would be so easy to generate a block that someone could generate multiple blocks at one time with their phone and double spend money.

Also there would be many more forks of the blockchain as multiple people would generate blocks at the same time and the network would have to figure out which is correct. This would result it lots of invalidated transactions. Business would have to wait even longer for the blockchain stabilize before accepting payment because they wouldn't be able to trust that a transaction is valid just because it's in a mined block.

Finally bitcoin would experience inflation at increasingly higher rates.

In short, it would be a disaster and completely kill bitcoin.

[wingding]

Yes, it would be a huge security risk as eventually it would be so easy to generate a block that someone could generate multiple blocks at one time with their phone and double spend money.

Also there would be many more forks of the blockchain as multiple people would generate blocks at the same time and the network would have to figure out which is correct. This would result it lots of invalidated transactions. Business would have to wait even longer for the blockchain stabilize before accepting payment because they wouldn't be able to trust that a transaction is valid just because it's in a mined block.

Finally bitcoin would experience inflation at increasingly higher rates.

In short, it would be a disaster and completely kill bitcoin.

But how come litecoin transactions are much faster? Does it have lower security?

[mgio]

Yes, it would be a huge security risk as eventually it would be so easy to generate a block that someone could generate multiple blocks at one time with their phone and double spend money.

Also there would be many more forks of the blockchain as multiple people would generate blocks at the same time and the network would have to figure out which is correct. This would result it lots of invalidated transactions. Business would have to wait even longer for the blockchain stabilize before accepting payment because they wouldn't be able to trust that a transaction is valid just because it's in a mined block.

Finally bitcoin would experience inflation at increasingly higher rates.

In short, it would be a disaster and completely kill bitcoin.

But how come litecoin transactions are much faster? Does it have lower security?

No, litecoin is basically the same as bitcoin except with a different mining algorithm and the average mining time adjusted to be 2.5 minutes instead of 10 minutes.

This is good and bad. The good part is that you don't have to wait as long for a confirmed transaction. The downside is that there will be 4 times as many blocks, so a much larger blockchain plus there is a greater risk of mining blocks at the same time so mining is more difficult.

[wingding]

A different algorithm? Does that simply mean a lower difficulty for litecoin blocks?

[mgio]

A different algorithm? Does that simply mean a lower difficulty for litecoin blocks?

No, it's actually a completely different algorithm. One that is much more dependent on memory usage in order to make it inefficient on GPUs. This didn't work though as GPUs are presently the fastest way to mine litecoins.

[wingding]

Ok thanks. You seem to know the tech-details here, so I keep asking:
I heard there is some cryptocur that avoid the 51% threat, is that correct, and how do they do that?

[veteranBtc]

Want faster blocks? Use another cryptocurrencies

[mgio]

Ok thanks. You seem to know the tech-details here, so I keep asking:
I heard there is some cryptocur that avoid the 51% threat, is that correct, and how do they do that?

I know that Litecoin is still vulnerable to the 51% threat. I don't know much about the other currencies so I'm not sure. If one of them claims to be immune to it, let me know and I'll read up about it.

[Sukrim]

Ripple is for example using something else than Proof of Work - they use consensus. That way they don't mine for their blocks and cannot be 51% attacked.

Other coins (I'm not sure if some are still alive) wanted to use Proof of Stake which means that to 51% the network you need to hold a big portion of the coins, not a big portion of the hash rate.

[deepceleron]

Yes, it would be a huge security risk as eventually it would be so easy to generate a block that someone could generate multiple blocks at one time with their phone and double spend money.

Also there would be many more forks of the blockchain as multiple people would generate blocks at the same time and the network would have to figure out which is correct. This would result it lots of invalidated transactions. Business would have to wait even longer for the blockchain stabilize before accepting payment because they wouldn't be able to trust that a transaction is valid just because it's in a mined block.

Finally bitcoin would experience inflation at increasingly higher rates.

In short, it would be a disaster and completely kill bitcoin.

Nobody is making blocks with their phone. This alone should disqualify any response to this post, but as the rest is wrong too, I thought I'd diffuse people taking anything you posted as a fact.

Double spends only happen (with non-malicious miners) when you trust 0 confirmations. If the blocks came faster there would be less reliance on 0 confirmation transactions for time-sensitive payments.

A faster block rate would actually result in the chain becoming less reversible faster. http://we.lovebitco.in/bitcoin-paper/#ch11
A 51% attack is only called that because someone will eventually be able to replace any amount of blockchain if they have a majority of hashrate. However, someone with a minority hashrate can also replace blocks if they are lucky.

For example, if there is a bad actor with 40% of the hash rate, it would take 89 confirmations before there is a less that 0.1% probability that they could replace any given block (real miners [pools with 45%] don't attempt this attack, because there is a very high chance they fail and lose all mining income earned on their incompatible blockchain branch). This depends only on the number of blocks, not the block finding rate. As a thought experiment, if block finding rate were to approach infinity, the variance would be completely removed and the highest hasher would always win a block race instantly.

Where the block rate becomes an issue is when considering network latency. It means a higher number of orphan blocks, but mainly impacting miners that find a block and transmit it before they get news that the network majority agrees another block was found first, resulting in a higher percentage of work wasted by miners. 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.

By inflation, you mean deflation, and no, a faster block rate doesn't need faster coin creation or a change in the coin creation curve.

Ripple is for example using something else than Proof of Work - they use consensus. That way they don't mine for their blocks and cannot be 51% attacked.

Ripple is, for example, using something else than mining, where the creator gives himself all the credits in block 0.

[deepceleron]

Where the block rate becomes an issue is when considering network latency. .... 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.

For a real-life example of what happens when you take bitcoin and give an insane rate of block finding, look at the failcoin launch of i0coin, where ArtForz was the largest independent miner (except for pools, where just a few seconds of latency made them find 0 permanent coins):

Confirmed Rewards   29669.89232442
*walks away whistling*

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.

[wingding]

I cant see that miners profits would have to change. More of the blocks they create will be rejected - yes. But they also produce more blocks, so it cancels out.

[DeathAndTaxes]

I cant see that miners profits would have to change. More of the blocks they create will be rejected - yes. But they also produce more blocks, so it cancels out.

The issue isn't profits it is wasted security.  Oprhans still require resources but they produce no revenue.  It is just electricity and capital expenditures (equipment costs) which go directly into the trash.  Worse an attacker will have no orphans.  The attacker doesn't care if his chain is behind as the goal of producing blocks isn't to collect the block reward.  As such an attacker will ignore all competing blocks until either his "attack chain" is the longest or he falls too far behind (mathematically improbable he can "catch up").  Most people are aware of the "51% attack" however attacks can (in theory) be done with less hashing power. 51% simply means that given enough time the attacker's chance of making the longest chain approach 100%.

The issue boils down to the fact that "good miners" produce orphans which are competiting wasted resources.   A chain with a hashpower of X and a orphan rate of Y really only has an "effective hashpower" of X * (1-Y).

Bitcoin currently has relatively small blocks and a 10 minute window and right now orphans rates are ~1%.  All things being equal (bandwidth, cpu power for verification, number of connections per node) as block sizes increase the orphan rate will also increase.  A smaller block window only magnifies that problem.

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. 

On a hypothetical blockchain with a 60 second EXPECTED block interval and a 12 second critical window ~20% of network's hashpower would be lost due to orphans.  The real security of the network would be 20% less than the headline number (i.e. XYZ COIN HAS 100 TH/s ... although only 80 TH/s provide security).

Orphans can be thought of as the inefficiency of the network.  Remember a shorter block interval requires more blocks for the same amount of security.  The one area that a shorter block interval has an advantage is first confirmation.  A business which operates on 1-confirmation model is better suited to shorter block intervals.  So it becomes 1-confirm advantage vs efficiency.

[Sukrim]

By the way with 2 block chains at equal hash rate (1 with 10 minute blocks, 1 with 1 minute blocks) it takes exactly the same amount of time to have the same amount of security. As difficulty will be 10 times lower on the faster chain, to have the same amount of confidence as 6 confirmations (1 hour) on the slower chain, you need 60 blocks on the faster one.

In the concrete example with Litecoin, also 6 confirmations on a 2.5(?) min average chain mean that (if everything else were just the same - hash rate and hashing algorithm, which they aren't) these 6 confirmations equal just 1.5 confirmations on Bitcoin at the same difficulty.

How many confirmations one requires to be sure that there won't be a double spend is up to the person receiving the money, so there might be an advantage in receiving initial confirmations faster if you require only very low security. These won't be as secure however as a slower, more difficult chain.

[Come-from-Beyond]

Ok thanks. You seem to know the tech-details here, so I keep asking:
I heard there is some cryptocur that avoid the 51% threat, is that correct, and how do they do that?

Qubic has adjusted percentage for a "majority" attack (http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=10&page=1#22).

Ripple is for example using something else than Proof of Work - they use consensus. That way they don't mine for their blocks and cannot be 51% attacked.

They use a special server for that, don't they?

[amincd]

As difficulty will be 10 times lower on the faster chain, to have the same amount of confidence as 6 confirmations (1 hour) on the slower chain, you need 60 blocks on the faster one.

This is not true. The probability of solving a block will always be the same for a given relative hashrate.

If you have 10% of the total network hashrate, you will have a 1/10 chance of solving a block, whether that block comes once every 10 minutes or once every 1 minute.

[Sukrim]

Yes, but 10% of blocks in an hour equal 6 1 minute blocks or 0.6 10 minute blocks.

If both chains have 1000 TH/hour, after 30 minutes miners on each of the chains were hashing 500 000 000 000 000 times. One chain however created 30 blocks/confirmations, the other one only 3 blocks/confirmations. Security wise (= how much work was put into the chains) they are equal though, so 10 confirmations on the fast chain would equal 1 confirmation on the slower one.

As there are more losses to orphans on faster chains, this is not 100% true, but I hope you understand now what I was trying to say.

[amincd]

Yes, but 10% of blocks in an hour equal 6 1 minute blocks or 0.6 10 minute blocks.

That doesn't matter, because the block generator in the 1 minute block chain will also be losing a lot more block races in that 1 hour.

The percentage of blocks the block generator solves is what determines their ability to pull off a double spend attack by creating six blocks in a row faster than the rest of the network.

If both chains have 1000 TH/hour, after 30 minutes miners on each of the chains were hashing 500 000 000 000 000 times. One chain however created 30 blocks/confirmations, the other one only 3 blocks/confirmations.

It doesn't matter how many hashes went into creating a block.* What matters is what the hashrate was to create that block.

*It actually does matter when it comes to renting hashing power to pull off a six block attack, but that's a different threat vector, as it can't be sustained for long.

[Sukrim]

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.

I would recommend to rather look at the amount of money it would approximately cost to double spend a transaction. For example a 1 GH/s miner costs 100 USD initially and 1 USD per day in electricity --> calculate how many of these you need to match the network hash rate and how much they cost to operate for a certain time frame. 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. You then can calculate how many blocks this would mean approximately. On a faster chain this would mean more blocks than on a slower chain, everything else equal.

[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.

[Xenland]

Broadcast it

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

Average: 100% of 1X = 1X

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

[amincd]

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.

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.

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.

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.

[Xenland]

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

[wingding]

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?

[deepceleron]

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?

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.

[tlr]

No, litecoin is basically the same as bitcoin except with a different mining algorithm and the average mining time adjusted to be 2.5 minutes instead of 10 minutes.

This is good and bad. The good part is that you don't have to wait as long for a confirmed transaction. The downside is that there will be 4 times as many blocks, so a much larger blockchain plus there is a greater risk of mining blocks at the same time so mining is more difficult.

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?

[amincd]

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 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.