51% attack cost page

[ademuanthony]

Fix #1022
This is a replacement for #1617
It is a continuation of work done by other developers on the 51% attack cost.
This PR adds a page for majority attack cost calculation for both internal and external attack type using network hashrate, ticket price and ticket pool size.
The user has the ability to adjust parameters like attack time, electricity cost, exchange rate and mining device, and see the attack cost in US dollar for every selected set of options.

[0xmzz]

UI is looking good. At a quick glance, the way the total attack cost is displayed makes it seem like there are two attack vectors (you need PoW + PoS for block production). Imo, dropping the word 'attack' in 'PoS attack cost' and 'PoW attack cost' wherever displayed would be better.

In addition, would it be possible to expose your local server so that we could check out the UI? it would allow for some quick feedback (I have used https://ngrok.com/ and it works really well).

[chappjc]

This looks like nice work. I can give you a full review this afternoon or tomorrow, but there are some issues that snuck in when you rebased.

[ademuanthony]

UI is looking good. At a quick glance, the way the total attack cost is displayed makes it seem like there are two attack vectors (you need PoW + PoS for block production). Imo, dropping the word 'attack' in 'PoS attack cost' and 'PoW attack cost' wherever displayed would be better.

In addition, would it be possible to expose your local server so that we could check out the UI? it would allow for some quick feedback (I have used https://ngrok.com/ and it works really well).

We have the test code running at https://explorer.planetdecred.org/attack-cost

[raedah]

Projected ticket price on external attack looks wrong. Some values show a ticket price lower than the current price. An external attack is always adding additional funds so all cases should show a rise in ticket price.

I can also suggest that 'additional costs' estimate be set to something other then 0 by default. 5% would be conservative. The amount being calculated should also be shown here instead of just put into the total.

[buck54321]

A couple of things to consider.

• You've plotted hashrate multiplier vs tickets, which is then used as an input the user can click to pick a particular value of tickets, which is then converted to a minimum attack cost. My question is why don't you just plot minimum attack cost vs tickets directly? The input parameter drawn from the click is already 1-dimensional, since all values are restricted to the minimum cost line anyway. At the very least, can the cost of attack value update as the user hovers around the chart?

• There is actually a relationship between ticket fraction, hashrate fraction and minimum attack time that you could leverage to drop the time input. If a user holds 'y' portion of the tickets and has 'x' fraction of the honest hashrate, and with a somewhat naive assumption that the honest hashrate did not change when the attack began, then the attacker would take t = 5/x to generate each block, and would not be able to validate (on average) until every 1/P blocks, with P from

(little p is stakeholder participation = 1 in your setup). (N k) is the binomial coefficient and is where all those coefficients in your rateCalculation function come from.

So it follows that the minimum average time to mine a single block is 5/xP. Here it is plotted against some hashrate multipliers.

[buck54321]

• About that naive hashrate assumption... There are actually two special cases that could potentially be used to establish a range of valid attack costs which is more realistic. What you're displaying is a sort of upper minimum attack cost, since you are assuming that the attacker is bringing on new hashpower rather than redirecting existing hashpower from the network. Presenting that info as the "correct" attack cost is misleading at best. A more likely scenario is that the attacker already controls some hashrate mining honestly on the network that is then redirected to their private network. This would appear as a large hashrate dip on the honest network, lowering the attack cost significantly. So if your calculation establishes an "upper minimum", the "lower minimum" is the case where all of the attacker's hashrate up to 100% of the pre-attack hashrate is also subtracted from the honest network.

[buck54321]

A couple of changes to request, but really great work. People have been asking about this forever.

[chappjc]

extras.tmpl is still reverting recent changes, probably a mistake in one of your rebases. After that is resolved, I'm good with this PR if @buck54321 is too.

[chappjc]

Thanks for undoing those extras.tmpl changes, but prefer not to introduce all those whitespace changes. I suggest to checkout master's version of the file and go from there.

[buck54321]

Encountered two issues. Was unable to reproduce the first. It was on a fresh build, fresh start, re-bundled web assets, cleared cache, etc. Keep an eye out for it. The chart was working fine initially, but then after refreshing it wasn't.

Seems that the ticket pools size is not being set in the controller element.

After waiting a bit, it eventually started working again, but something else is off.

We get some boost from hybrid consensus, but 3 trillion dollars is a bit high.

[ademuanthony]

Encountered two issues. Was unable to reproduce the first. It was on a fresh build, fresh start, re-bundled web assets, cleared cache, etc. Keep an eye out for it. The chart was working fine initially, but then after refreshing it wasn't.

Seems that the ticket pools size is not being set in the controller element.

After waiting a bit, it eventually started working again, but something else is off.

We get some boost from hybrid consensus, but 3 trillion dollars is a bit high.

I am unable to reproduce this issues on a fresh build even after clearing my cache and trying from another web browser

[ademuanthony]

I am unable to reproduce this issues on a fresh build even after clearing my cache and trying from another web browser

I think this PR can be merged and for the issue pointed out, a follow up PR can be created for the bug when it is isolated.

[raedah]

Im seeing errors in the calc that are causing external attack to show with negative numbers which should not occur.

[ademuanthony]

I have two pending issues on this PR

• One is to make the target PoW attack input editable and use the value to calculate the attack cost
• The second one is to get clarity on how to calculate the expected hash rate for an external attack for a giving ticket percentage

[0xmzz]

Regarding the target PoW attack input being editable, the slider already solves this issue and that is why I thought a slider would be a good idea. However, if we want the hashpower to be an input we would solve for equation (6 (1-stake)⁵ -15(1-stake)⁴ + 10(1-stake)³) / (6stake⁵-15stake⁴ + 10stake³)=%hashpower and I am not sure how to do that in JS.

[raedah]

Ive tested the latest version of this and it looks good to go. What is here works, and it would be good to have it merged to see it get some use and feedback. There are several areas for enhancements that can come in later PRs.