Topic: Would faster block creation give lower security? - page 2. (Read 3136 times)

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

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

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

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?

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

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.


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.


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.

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.

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.

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.


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.

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.

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.

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



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

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.

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.

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.

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):

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 mining, where the creator gives himself all the credits in block 0.

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.

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.

Want faster blocks? Use another cryptocurrencies