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.

[1714971488]

1714971488

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