<p>I believe you are asking if the inter-block interval matters for the success rate of a high hashpower reorg attack.</p>

<p>It does, because if it is too fast the honest participants will spend a substantial fraction of their time not working on the same (honest) chain, because they haven't heard of each others blocks or have created their own blocks before other honest blocks arrived.</p>

<p>So the attacker pillages the village while the defense is diluted and not working together perfectly.</p>

<p>Slowness in this case is always relative to the overall processing and propagation time. So a system which worked without substantial dilution normally could run into problems when flooded with transactions or if an attacker started also DOS attacking nodes.</p>

<p>Mining a block is memoryless, but mining a <em>chain</em> makes progress. But both the attacker and the honest network make progress, so when considering their relative advantages their success depends on their relative hashrates.  If in fact the honest network takes longer (due to bad luck) to mine this particular block then it is easier for an attaker to be successful during that time.</p>

<p>So, for example, in your risk calculation if you observe that blocks have been slower than expected recently it may be reasonable to require more confirmations for two reasons: One reason is because if the honest network was unlucky an attacker with a secret chain might have done better with only average luck. Another reason is because the reduced block speed may in fact be because part of the network has split off to attack.</p>

CC BY-SA 4.0
2018-11-30T11:20:18.570Z
Why is transaction flooding considered DOS? They are anonymous, pay a sufficient fee for propagation, and any validating node can restrict mempool acceptance criteria if resources too low, or forego mempool altogether.
James C.
CC BY-SA 4.0
2018-11-30T13:14:26.823Z
Fee is not for propagation, it's for getting into a block. Also he said "flooded with transactions OR DOS" not necessarily equating the two.
Jannes
CC BY-SA 4.0
2018-12-01T08:51:56.263Z
Ok. Minimum fee is also required for propagation (node policy, see libbitcoin server). Of course fee ultimately for confirmation payment.
James C.
CC BY-SA 4.0
2018-12-01T09:44:49.463Z
A transaction that never confirms never pays a fee.  Moreover, at _best_ a fee can make an attack more expensive, it is not a magic totem that turns an attack into not an attack. :)
G. Maxwell
CC BY-SA 4.0
2018-12-01T10:23:50.907Z
unrelated, libbitcoin isn't actually used on widespread basis in Bitcoin so generally you shouldn't use it as a benchmark of what Bitcoin does in practice. (though on there being minimum fees used it's consistent)
G. Maxwell
CC BY-SA 4.0
2018-11-30T10:55:34.457Z
2018-12-01T05:32:00.657Z
2018-12-01T05:32:00.657Z
G. Maxwell
<p>I'm new here. 
I have  a question here. Some experts keep saying that this assumption isn't formally correct and I don't really understand why or why they might be wrong.</p>

<p>In the double spend attack; you have attacking network and honest network. 
Total Hash rate is split between those. </p>

<p>some experts keep saying that time is not a factor in determining how fast you can generate blocks. That's something I don't really get.</p>

<p>So, is it incorrect to say that the probability of success of the attacker
increases with the time T it takes to generate z transactions since they have more time to secretly mine their alternate blockchain ?</p>

<p>update:
@G. Maxwell. I am not sure what i am asking for exactly. So let me try this.</p>

<p>Perhaps I am asking whether the assumption that the time to mine blocks is memoryless ? And how this clashes, if it does, with the proposition that the probability of success an attacker increases with time T it takes to mine the z transactions since they have more time to secretly mine their alternate blockchain. 
I am not assuming any other external attacks other than mere hashpower. </p>

CC BY-SA 4.0
2018-12-01T05:32:21.007Z
I added some text that might answer your requested clarification.
G. Maxwell
<doublespend><majority-attack><race-attack>
double spend attack: Is this actually true for the more time progress the higher the probability of success for attacker
fritz
# double spend attack: Is this actually true for the more time progress the higher the probability of success for attacker

(Asked by: username_0 on 2018-11-30)

I'm new here.
I have a question here. Some experts keep saying that this assumption isn't formally correct and I don't really understand why or why they might be wrong.

In the double spend attack; you have attacking network and honest network.
Total Hash rate is split between those.

some experts keep saying that time is not a factor in determining how fast you can generate blocks. That's something I don't really get.

So, is it incorrect to say that the probability of success of the attacker
increases with the time T it takes to generate z transactions since they have more time to secretly mine their alternate blockchain ?

update:
@username_1. I am not sure what i am asking for exactly. So let me try this.

Perhaps I am asking whether the assumption that the time to mine blocks is memoryless ? And how this clashes, if it does, with the proposition that the probability of success an attacker increases with time T it takes to mine the z transactions since they have more time to secretly mine their alternate blockchain.
I am not assuming any other external attacks other than mere hashpower.

**Tags:** doublespend, majority-attack, race-attack

> **Comments:**
> **username_1**: I added some text that might answer your requested clarification.  

---

## 1 answers

### Answer by username_1 on 2018-11-30. Score: 2

I believe you are asking if the inter-block interval matters for the success rate of a high hashpower reorg attack.

It does, because if it is too fast the honest participants will spend a substantial fraction of their time not working on the same (honest) chain, because they haven't heard of each others blocks or have created their own blocks before other honest blocks arrived.

So the attacker pillages the village while the defense is diluted and not working together perfectly.

Slowness in this case is always relative to the overall processing and propagation time. So a system which worked without substantial dilution normally could run into problems when flooded with transactions or if an attacker started also DOS attacking nodes.

Mining a block is memoryless, but mining a *chain* makes progress. But both the attacker and the honest network make progress, so when considering their relative advantages their success depends on their relative hashrates. If in fact the honest network takes longer (due to bad luck) to mine this particular block then it is easier for an attaker to be successful during that time.

So, for example, in your risk calculation if you observe that blocks have been slower than expected recently it may be reasonable to require more confirmations for two reasons: One reason is because if the honest network was unlucky an attacker with a secret chain might have done better with only average luck. Another reason is because the reduced block speed may in fact be because part of the network has split off to attack.

> **Comments:**
> **username_2**: Why is transaction flooding considered DOS? They are anonymous, pay a sufficient fee for propagation, and any validating node can restrict mempool acceptance criteria if resources too low, or forego mempool altogether.  
> **username_3**: Fee is not for propagation, it's for getting into a block. Also he said "flooded with transactions OR DOS" not necessarily equating the two.  
> **username_2**: Ok. Minimum fee is also required for propagation (node policy, see libbitcoin server). Of course fee ultimately for confirmation payment.  
> **username_1**: A transaction that never confirms never pays a fee.  Moreover, at _best_ a fee can make an attack more expensive, it is not a magic totem that turns an attack into not an attack. :)  
> **username_1**: unrelated, libbitcoin isn't actually used on widespread basis in Bitcoin so generally you shouldn't use it as a benchmark of what Bitcoin does in practice. (though on there being minimum fees used it's consistent)  

---

