BUIP038: (closed) Revert "sticky gate"

[adamstgbit]

@dgenr8
i made a bunch of edits, but you probably got the gist anywho.
yes i realize its very similar to BIP100
but my suggestion is really BUIP001 + BIP100
I'm saying keep all that BU emergent consensus MG EB AD as is, but also have a easy to calculate upper limit.
the attacker is now "declawed" if he's lucky enough to successfully attack the network the biggest block he can hope to force onto the network is a fixed size..

 

[theZerg]

@dgenr8, the problem with all the vote-in-blocks systems are liars. If a liar successfully gets something "activated" but the majority (the liars + the resisters) do not activate, then a large minority are forked of onto their own chain. So you don't know if consensus is actually achieved until you attempt to activate. So there IS no consensus when you were saying it occurred. And after activation, you will learn that consensus was not achieved because of orphans. This is the exact same way you learn about it in EC.

[No I don't think its likely that a large minority of hash power will be liars -- and I don't think a large minority will execute a huge block attack either. The huge block attack is even more costly then the "lying" attack because in it the minority is orphaning itself... for no financial advantage]

I didn't invent emergent consensus because its the best solution, I invented it because its the only solution.

These "higher layer" voting protocols aren't provably correct, which is why in BU the EB reporting doesn't algorithmically feed into a change to the max block generation size.

EC is more fundamental than these voting algorithms... for example, you can easily implement the voting over EC. Just tally up the EBs of the last 1000 blocks and if over X% vote for > 1MB (or whatever), then change the max block generation size N blocks later. It would be just a few LOC... how is that different than BIP100 or others?

But we don't do this because of the lying problem. Instead, we expect that the miners may make a similar agreement personally, human-to-human. That way, people intuitively understand that other participants may be lying...

 

[dgenr8]

False signaling is only a problem when the effect of the signal is undefined. When your signal is part of the algorithm, it is genuine.

The only nodes who can get forked off with BIP100 are those who are not running it. Your point boils down to stating that people can run whatever they want. That suggests nothing about how to design the software.

Yes, reorgs are possible, and just as with difficulty, they result in a history change -- but for a given block's children, you know the target difficulty and the max blocksize.

Just as with difficulty, the main reason you follow the rules is that you believe others will. You say "you can easily implement the voting over EC." Well yes, some miner could distribute a patch set to implement BIP100. Now they are the software provider -- which is fine, but don't they want us to do that job?

There is nothing unfair or offensive about a published algorithm -- especially one that is recalculated every 2 weeks. It benefits everyone, especially miners.

 

[adamstgbit]

after much thought i have concluded thezerg's BUIP041 is the best solution.

I think dgenr8 makes a pretty solid point, sure miners can (and probably will) add a few LOC, but isn't that BU's job?

... its not, BU provides the most "fair", "cut throat?", "free!", playing field possible and let the participant play.

i believe the BUIP covers the hypothetical problem nicely and completely.

I believe the argument that it is complex and creates "code dept" is bad because there is literally nothing stopping anyone from completely scrapping that AD calculation and replacing it with there own thing..
I mean its not a requirement that the node behaves this way its merely the reference implementation to get a good/safe AD value.

it "would be nice" if nodes could calculate a blocksize limit and use it as a hard limit, but playing god to bitcoin isn't about "being nice"

my vote will go to BUIP041

 

[adamstgbit]

@dgenr8, the problem with all the vote-in-blocks systems are liars.

imagine you have 48% hashing power, how do you control the Median EB value listed on the last 1000blocks?
there's no way. best you can do is BE the Median, but are you kinda powerless to control it's value.

edit: thats not entirely true, you could force the highest values honest miners are voting for be the Median, or you could have the lowest value honest miners are voting for be the median. well point is if you look for Median, then honest miners will get to set that value so long as at least 51% of miners are honest.

hmm.... i'll just be quiet now

 

[sickpig]

All,

I poked a bit trying to find out what's the actual cost of a successful attack given an AD value and the amount of hashpower that an attacker have at his disposal.

You could find all the data here:

https://docs.google.com/spreadsheets/d/15PFggIxjhMwRZ3WXfFELsstvRvyYwKB4EIX26LhfMY8/edit?usp=sharing

Let me just summarize how I manage to get to the cost of the attack.

1) use @awemany / @dgenr8 method to compute a probability of a single
successful event, P(e) 3rd column, given a particular value of AD and
attacker hashrate, p (1st column).
(see https://gist.github.com/awemany/d9d2eb0eb17c4c51b896df13fbfd0def)
P(e) could be computed using a Binomial distribution or an Erlang distribution the
script provide both

2) Calculate the number of trials to first success (4th column). Such number is
equal to 1/P(e). Demonstration available here:
http://www.cut-the-knot.org/Probability/LengthToFirstSuccess.shtml

3) Now we need to know how many blocks an attacker is going to main for every trial on avg.
Since every trial is just a Bernoulli process (https://en.wikipedia.org/wiki/Bernoulli_process)
and the number of mined blocks in the first 2*AD+1 step has a binomial distribution with
parameter n = 2*AD + 1 and prob of success p (attacker hash rate). The avg number of block
per trial will be n * p = (2 * AD + 1) * p
Such number is placed in the 6th column

4) Finally in the last column you have the cost of a successful attack in USD given the
current exchange rate (~775$). To use @dgenr8 word: "[the] cost is measured by
the time spent mining on a chain known not to be longest."

The formula is pretty simple:

12.5 * btc_value_in_usd * (AD + 1) + 12.5 * btc_value_in_usd * (1/P(e) -1) * ((2*AD+1) * p)

the first term is the cost of single successful attack it means, here you need to mine AD + 1
block faster than the honest part of the network

the second term is the avg mined block per failed attempts (2*AD+1) * p multiplied by the
number of trials to first success minus one (1/P(e) -1) multiplied by the value in usd per block
(12.5 * btc_value_in_usd)


Summarizing:

* increasing the AD increase the cost of the attack in a superlinear way.
* If an attacker has more that 30% of the hash power the cost of the attack is relatively low.

on the other hand as you can see increasing the AD significantly increase the cost exponentially.

this is the same that for an attacker with the 25% of the hash rate:

 

[adamstgbit]

@sickpig

the cost you outline only takes into account the 12.5BTC in lost revenue per attempt?
i think if you take into account the lost fees
and also the cost of electricity wasted.
also managing 25% hashing power isn't free...

i think the real costs will be double what you've estimated.

 

[sickpig]

@adamstgbit

good point you're right I didn't take into account energy, maintenance cost and fees. I'll update it accordingly.

I'm going to use something like 5% for estimating the fee, for energy cost I'm going to take the best case scenario for the attacker, so very low energy cost ( 0.08$ / KWH) and efficient asics (bitmain s9).

That said I'm not considering only 1 block per failed trial, but the avg mined blocks per failed attempts that it is equal to (2 * AD + 1) * p. So if you have 30% of the hashrate with an AD equal to 5 you're going to mine 11*.3 = 3.3 blocks.

 

[sickpig]

@adamstgbit

I've update the cost of the attack adding fee and energy cost.

the url is always the same https://docs.google.com/spreadsheets/d/15PFggIxjhMwRZ3WXfFELsstvRvyYwKB4EIX26LhfMY8/edit?usp=sharing

For the fee I've estimated a cost equal 5% of the block reward, for the energy cost I've supposed the attacker is going to use one of the most efficient miner on the market antminer S9 (14 TH/s per unit, 1378 Watt at the wall) with and a very low cost per KWH 0.05$.

Given that data one S9 in a day consumes ~1.6$ of energy.

To have an estimate of the energy cost of a successful attack I've used the following formula:

avg trials to success * single trial duration in days * [(net hashrate in TH/s * % of attacker hash rate) / 14 * 1.6$]

where

single trial duration in days = [(AD + 1) + avg block x failed trial ] * 10 mins / 60 / 24

because in each trials failed trials honest part of the ner will mine AD + 1 block where as the attacker will mine a bunch of blocks according to his hash rate (avg block x failed trial).

Updated cost for the 25% attacker:

and for the 35% attacker:

So as you can see the cost increase significantly.

take into account that I didn't update the btc value in usd.

 

[deadalnix]

There are various problem with you analysis. First, you shouldn't use $ as it is obviously a cost in TC we are talking about. This brings in a ton of variable that are essentially irrelevant and obscure the important data.

What you are interested in here is the opportunity cost of the attack. Namely, how much more money the attacker could have made by playing nice.cost in energy and whatnot are irrelevant as they are the same either way.

So you want to compute how many BTC the miner would have mined if it would just follow the main chain, minus how many BTC the miner would make by following the alternative strategy. The difference between the 2 is called the opportunity cost and is what we are interested in here.

Second, I'm not sure how you compute the expected day required for an attack to succeed.

Third, and IMO that is where the thing falls short, is that the attack scenarii contradict themselves. The assume an uniform EB/AD, but, on the other hand, assume that at least 25 to 35% of the networks wants a different AD. This isn't compatible. Digging in that direction we can reason that ED/AD must not be uniform in the scenarii we are looking at. As a result, we have an acceptance curve, with for instance 100M of the nodes accepting 1MB, 90% 2MB, 60% 3MB, 50% 4MB, 35% 1TB (the attacker group). We clearly see in that scenario that there is a gradation of the cost and success rate of the attack as more or less nodes will accept the block. In addition with the time required to transfer the block 6 blocks, this makes a huge block chain very likely to be orphaned, while a miner can push the limit up gently over time at a much lower cost.

As a result, I don't think the attack is very credible. An attacker can have larger block over time at a fraction of the cost of going rogue. Unless what the attacker wants to do is actually destroy the network, but in which case the cost of the attack needs to include initial investment, aka the price of the ASICs required to run the attack, as they'll be made mostly worthless.

The current hashrate is about 2EH/s, so 35% would mean about 700PH/s . That is about 50 000 S9 or about $100M in investment you need to add to the cost of the attack. On a side note, this is why ASIC mining is good, it makes hostile mining absurdly expensive.

 

[awemany]

@sickpig: I am still pondering about the right cost metric to use. How do you decide on the outcome of an attack, if not after mining K blocks and seeing whether you are faster than the main chain?

@deadalnix :
On the opportunity cost, shouldn't that be (assuming an efficient mining market) roughly be two times the block reward, so a simple factor of two? So yes, I missed that one above.

 

[deadalnix]

The opportunity cost is the the money you lose not doing something more profitable. For instance if I go work at McDonald, then I'm making money. But my current salary is higher than what I'd make at McDonald. Therefore, my opportunity cost to work at McDonald is - currentSalary - McDonaldSalary .

In this case this is what you want to compute. How much BTC the miner would make playing nice, and how much money does the miner makes trying to pull your scenario. The difference between the 2 is the cost of the attack. What the attacker actually spend is not that relevant, unless the amount are low trivial.

 

[awemany]

@deadalnix: Right, so nothing missing and I am getting confused again...

I am still pondering why this is not proportional to (AD / probability-of-success), though, as @sickpig seems to suggest. I am kind of lost where he's going with his calculations.

 

[adamstgbit]

@deadalnix

i would argue that what the miner has to spend is more important then what the miner's lost opportunity cost.
if we imagine that the miner is a government that wants to destroy/disrupt bitcoin, the fact that he could be making more money minning bitcoin is totally irrelevant.
with that said the energy cost are mind blowingly scary low!

altho i think sick pig is really downplaying energy costs, cooling the hardware is not consider, etc etc.

i thought mining bitcoin was a very marginal business, minning 12.5BTC cost like 13.5BTC if you're not doing all the right things. i guess the mining space has not kept up with the price increases, minning is profitable again.
[doublepost=1482078934,1482078123][/doublepost]the cost analysis, is pushing me back toward the idea of a supplementary hard upper limit based on median EB values reported in the last 1000 blocks.
https://bitco.in/forum/threads/implicit-blocksize-limit.1664/

 

[sickpig]

First, you shouldn't use $ as it is obviously a cost in TC we are talking about. This brings in a ton of variable that are essentially irrelevant and obscure the important data.

USD has been used for simplicity's and clarity's sake and more to the point I want a model that produce some good enough data even if not perfect.

What you are interested in here is the opportunity cost of the attack. Namely, how much more money the attacker could have made by playing nice.cost in energy and whatnot are irrelevant as they are the same either way.

The aim of the attacker is open the gate and after that flood the BU note with a bunch of extremely big blocks, to ulteriorly partition the net, DoS BU nodes and whatnot. This is the hypothesis on which the above calculation is based, along with the fact the all the honest miners will have the same AD.

This is of course a way to simplify the scenario to get some real number to deal with.

Once the attacker reach his goal he gain nothing in monetary term cause the "BTC" mined on the attacked cost will have no market, hence 0 value.To that add the fact that energy cost he sustained was real.

So the amount of money he gain from attacking are negative in the short term, in the long term the attacker succeed to keep only one chain alive (his own) and instill fear and uncertainty in an other actors who want to hard fork in the future.

That said if instead of attacking it would have used his hashrate to properly mine he would have spent all the energy cost computed and gained all fee and block rewards in the process (earnings = block + fee - energy).

So the TC in this case is:

TC = Gains from attacking - Gains from being honest
TC = - energy cost - (block + fee - energy)
TC = - block - fee

So even in the case of an uniform AD there's no reason why an actor would rationally perform an attack if it will take into account only near term cost analysis. But as I said already may the attacker goal is more long term, e.g. avoid future hard forks attempt, or maybe he's guided by irrational motives.

Second, I'm not sure how you compute the expected day required for an attack to succeed.

10 minutes per block * number of blocks needed to perform a successful attack given an AD value and p (attacker hash rate).

The avg # of trials to first success is 1/P(e) (see http://www.cut-the-knot.org/Probability/LengthToFirstSuccess.shtml).

The avg # mined blocks by the attacker in every failed attempt is equal to (2*AD+1)*p, since every trial is will follow a Binomial distribution B(n,p), where n = 2*AD+1 (max number of mined block per attempt by all parties and p is the attacker hast rate). See https://en.wikipedia.org/wiki/Binomial_distribution#Mean

For each attempt then we have to take into account mined blocks from all actors (attacker and honest parties). So for each attack we will have (AD+1) + [(2*AD+1)*p].

So the time spent on a successful attack in days will be:

1/P(e) * {(AD+1) + [(2*AD+1)*p]} * (10 / 60 / 24).

Third, and IMO that is where the thing falls short, is that the attack scenarii contradict themselves. The assume an uniform EB/AD, but, on the other hand, assume that at least 25 to 35% of the networks wants a different AD.

The assumption is simple: the attacked network share the same AD settings and the attacker is going to produce an EB = max(EB_i) (i=1..n, where n are the distinct EB value on the honest side). Maybe too simple but I was searching for quick way to evaluate the risk in monetary term. The AD/EB settings of the attacker are irrelevant.

The current hashrate is about 2EH/s, so 35% would mean about 700PH/s . That is about 50 000 S9 or about $100M in investment you need to add to the cost of the attack. On a side note, this is why ASIC mining is good, it makes hostile mining absurdly expensive.

I've purposely left HW acquisition cost since I framed the attack coming from already existing player. You have a point here though, among others increasing the cost for an external attacker is another positive factor of ASIC mining.

 

[sickpig]

altho i think sick pig is really downplaying energy costs, cooling the hardware is not consider, etc etc.

Yeah didn't take into account cooling or using the produced hit to do something valuable.
Other things I did not take into account are:

- HW acquisition
- Maintenance cost: man power, renting/buying space for the facilities itself

I've expanded a bit in the prev posts the reasons why I did it that way, but to make a long story short, the aim of the above cost analysis is give a rough idea of the amount of time and monetary effort someone has to pour into this endeavor. Nothing more nothing less.

That said everybody's effort to improve the model is more than welcome. Just clone the spreadsheet file and hack on it or chose the tool you prefer

 

[adamstgbit]

@sickpig
its a really good approximation.
I think we can all agree the attack would probably cost a little more given other factors, but your numbers calculate fairly accurate / relevant INFO.
thanks for this!

 

[deadalnix]

if we imagine that the miner is a government that wants to destroy/disrupt bitcoin, the fact that he could be making more money minning bitcoin is totally irrelevant.

I addressed that scenario as well and you chosed to ignore it. In that case, the calculation needs to include the initial hardware investment.
[doublepost=1482122367][/doublepost]

I've purposely left HW acquisition cost since I framed the attack coming from already existing player. You have a point here though, among others increasing the cost for an external attacker is another positive factor of ASIC mining.

That's not how it works. Let's we plan to do something bad - it doesn't matter what - but the plan involve to destroy your car. You tell me that the cost is not worth it, because your car is valuable to you. What would think if I answered you "it doesn't matter what the cost of the car is, because you are an existing car owner, you already have the car".
[doublepost=1482122791,1482122106][/doublepost]

Yeah didn't take into account cooling or using the produced hit to do something valuable.
Other things I did not take into account are:

- HW acquisition
- Maintenance cost: man power, renting/buying space for the facilities itself

All these parameters, but hardware acquisition, are moot. Hardware acquisition is also moot if the network isn't destroyed, but needs to be taken into account if this is the objective.

If you want to price the attack, you need to compare it against the alternative scenario, not against the miner having a bunch of ASICs and not running them at all. Electricity, cooling, man power and alike are the same regardless what is done with the ASICs, so they don't matter.

The difference include:
- Unrealized benefits
- If the network is effectively destroyed, the devaluation of assets - an ASIC is just an overly expensive and noisy piece of heating equipment if there is no coin to mine.

The facility itself will not be devalued, the rent needs to be paid no matter what, the electricity price is identical, and so on. All these parameters aren't interesting. You may want to translate the price of the attack in USD, but looking at the price of resource and trying to evaluate how much is used is the wrong way to go about it.

 

[adamstgbit]

Electricity, cooling, man power and alike are the same regardless what is done with the ASICs, so they don't matter.

ya expect in one case, all that junk turns a profit!
and in the other case, all that junk... doesn't... turn... a... profit....

i think there are many variation of this attack with different kinds of cost

for example

you have 20% hashing power saying EB is 8MB ( but you're lying )
some 40% of hashing power says EB is ~4MB
the other 40% of hashing power says EB is 16MB

you can safely mine 16MB blocks and have 40% of the network kinda get F'ed up for AD blocks.
there's a huge incentive to do this.
1) you can safely reap more fee
2) you're more likely to find more blocks !! ( sure you'll find them slower but you get a bit of a head start minning on the right blockchain while 40% of the network is Forked for AD blocks!)

normal use of EC??? probably not...

how about this one:
50% of the network say 2MB the other 50% say 16MB
someone mines a 8MB block

normal use of EC??? maybe!

There are many many variation of exploiting EC EB and AD to your advantage.
Altho i think most of these are unlike, but example #1 is MOFO profitable!

where do we draw the line? what is normal use of EC and what is an attack?

all these "attacks" go away if we implement this: https://bitco.in/forum/threads/implicit-blocksize-limit.1664/

 

[deadalnix]

ya expect in one case, all that junk turns a profit!
and in the other case, all that junk... doesn't... turn... a... profit....

I'm not sure if you are getting it by now or are still missing the elephant in the room. Yes, that' the difference. The profit you make or not make is the difference. This is the cost of the attack. This is what needs to be measured.