Related Question: What can be done to mitigate the risk of a Finney attack?

The Finney attack is a form of double-spending attack where the attacker pre-mines a block containing a conflicting transaction and then publishes a transaction. A merchant relies on the published transaction to do something irreversible. The attacker then succeeds if he can publish the pre-mined block after the merchant has committed and before the network can find a different block. (The merchant must act irrevocably on a published, but unconfirmed, transaction.)

It has been suggested (by David Perry) that reducing the block generation time will make the network more resistant to this kind of attack. The reasoning is (I assume) that the window in which the attacker can launch the attack, the time after he publishes the transaction and before that transaction gets into a block, would be smaller. However, I don't find this argument convincing.

First, the attacker can stretch the interval by creating a burst of meaningless transactions using older coins or with small transaction fees. He can gather lots of new inputs into his transaction to reduce its priority. Thus, he can make it very unlikely that his published transaction will get in the next block found by the network anyway.

Second, with a faster block generation time, the difficulty will be lower. The attacker has to wait until he's lucky anyway. So maybe he can just wait until he mines two blocks ahead of the network. Then while it's more likely the network will find a block before he can complete his attack, the network has to find two blocks, not just one. And meanwhile, he can keep looking for even more blocks. (Imagine he is conspiring with a mining pool that has, say, 30% of the network's hashing power.)

So what is the correct analysis? Would a faster block generation time really make any difference to the effectiveness of Finney attacks?

1 Answer 1


Assuming all else is equal (same network hashrate, etc) then the attacker still represents the same percentage of the overall hashrate and therefore may claim the same percent of the blocks for his/her attack. While it's true that faster block time increases the total number of blocks, reduces the difficulty and makes it so that the attacker has more opportunities to land an attack with the same hashrate it also lowers the detection time for such an attack and narrows the window.

In the standard Bitcoin network, a block is found roughly every 10 minutes, but realistically they are found along normal distributions with their peaks at 10 minute intervals. A block may be found immediately after another block or it may take 20 minutes to find the next block, but these are not typical cases. I don't have data to show what one standard deviation from the 10 minute mark would be, but I can say that if block time were reduced such that the region of +/- 1 standard deviation overlapped slightly, an attacker would face a statistically significant risk of a block being found before he or she could execute the Finney attack. I have no idea what other effects this might have on the network, and it would require significant testing to confirm its feasibility.

Even if the +/- 1 SD region did not overlap, the distance between their boundaries is effectively the period of time an attacker has to execute an attack, so anything which narrows this gap reduces the effectiveness of a Finney attack.

The active question which I've still not found an answer to, is this: Does the value of σ² for the distribution of block finds change along with average block time or is it somewhat static? If σ² remains the same then decreasing the block time will drastically effect the ability of an attacker to utilize this method, but if it decreases proportionally to block time then the only effect block time has on such an attack is the added requirement of greater precision in timing.

Edit: I've received confirmation that block generation isn't a normal distribution but rather a Poisson distribution and that the time window for a Finney attack does scale linearly with block time. To this end, reduced block time provides no statistical advantages over normal block time, but it does still require an increase in precision on the part of the attacker. As I've not heard of anyone executing a Finney attack, even as a proof-of-concept it's questionable how much the precision requirement would help in preventing attacks, though the effectiveness of such is probably more dependent on the merchant/business model than on the network itself.

  • Just realized some browsers may not correctly display "σ²" - for those who get blocky nonsense instead of pretty Greek letters that's "sigma squared" or the variance of the normal distribution. Sep 22, 2011 at 16:49
  • Small correction/addition: the time between two blocks is not distributed normally but follows an exponential distribution with λ=10min^(-1). The standard deviation of this distribution equals the mean time between consecutive blocks - it therefore overlaps regardless of the block time.
    – Noah
    Sep 22, 2011 at 16:57
  • Sorry, please disregard the last sentence above - I was too slow to edit. What I wanted to add: Since the block generation itself is a Poisson process, the probability of a block being found within any fixed-length time interval is always the same. The time-window for a possible Finney attack therefore scales linearly with the average time between blocks.
    – Noah
    Sep 22, 2011 at 17:15
  • Good to know, I'll edit my post with this new information. Thanks! Sep 22, 2011 at 17:26
  • I tried calculating the standard deviation of the time it takes for blocks to be found, but it's hard because the time stamps on blocks isn't accurate. Sometimes the timestamp on a block is earlier than the timestamp on the previous block. See for example blocks 163966 (2012-01-26 19:52:37) and 163967 (2012-01-26 18:41:05). Given this, the average over the last year is 546 seconds, and the standard deviation is 593 seconds. Feb 7, 2012 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.