BUIP038: (closed) Revert "sticky gate"

[sickpig]

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

One of the working hypothesis is that the attacker already own the HW.

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.

In this scenario the attacker want to destroy the value of the big block branch not the entire net work.
So even in the case the attacker is going to buy a bunch of new shiny S9, he could still use them on the his chain after the attack.

That said you could add a column with the HW cost, which will be a function of the hashrate used in the attack and share the result with us.

 

[deadalnix]

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

Dude, there is an if in there. I put the if in there for a good reason: it affects the meaning of the sentence. If you are quoting something, make sure you respond to that thing.

You count the price of the ASICs if they are made worthless, you don't if they aren't. And the fact that the attacker already owns the ASICs before hand or buy them to pull the stunt is irrelevant. For instance, I'll give you 1BTC if you burn your house down. Will you do it ? No ? But you already own that house, so that's not a cost !

 

[sickpig]

@deadalnix cool bro

I was just trying to clarify the scenario the model apply to.

This is what I'm saying: the model I proposed does not take into consideration the HW cost because of the existence of these 2 working hypothesis:

- the attacker already owns the HW, the same HW he was using to do his work before the HF.
- the attacker will use all his HW to perform the attack.
- the attacker will continue to use such HW on his own fork once he destroyed the other branch one.

 

[deadalnix]

That hypothesis is covered by my posts, since the very first one, and the number presented are still not the interesting ones.

 

[adamstgbit]

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.

there is no monetary gain, in doing this attack.

 

[deadalnix]

Then the gain is 0. Yes or no do not make sense for a numeric value.

 

[adamstgbit]

and the cost X
and with thezergs solution the cost is X*Y
where Y the factor by which your EB has been violated
I think.
so 25% minning a block 160MB big, while your most EB values are set at 16MB, will "cost" 10million dollars, and most likely be be countered with other miners/nodes simply increasing AD temporarily ( while the attacking hash power quickly drives himself bankrupt )

and, worth noting that, just because AD was reached and "the node's AI" switched to that chain does not guarantee the miner will now forever mine that chain.

the attacker has to be 1) stupid 2) rich as fuck 3) not care about becoming stupid and poor.

now i dont know whos up for that task....

 

[sickpig]

That hypothesis is covered by my posts, since the very first one, and the number presented are still not the interesting ones.

[the total gain in this case is < 0]

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.

That said, I'm sure it's me, but I quickly re-read your posts and still I don't clearly get your point. Do you care to summarize it here?

 

[jonny1000]

Sorry to comment here, as I know I am unpopular and I know there is a closely contested vote on this going on right now.

Can somebody please explain why the sticky gate rule is not as follows:

If a block is produced above the local EB threshold and receives AD confirmations, a sticky gate is opened for 144 blocks, where blocks with a size up to that of the orignal excessive block, are immediately considered valid on one confirmation.

I asked @theZerg this a while ago and got no response. Does this not mitigate much of the problem in a more simple way? I am sure there is a simple reason this will not work, but I just do not know it.

 

[adamstgbit]

@jonny1000
I guess OP proposing somthing similar " it should not be sticky "

the stickyness of the gate is meant to ensure that once AD blocks have been reached your node will forsure stay on that longest chain.

so that is why the rule was hard and fast, "after AD blocks, give up the fight"

i think theZergs BIP is best, it considers by what factor your EB has been violated and increases AD respectively. which is, basically what you'd expect anyone to do manually.

 

[jonny1000]

@jonny1000
I guess OP proposing somthing similar " it should not be sticky "

I thought the OP was saying BU should totally removes the gate. As @theZerg explained, the problem with this is that it makes the network far more divergent. For example, miners with a lower EB setting than the "current level" will always be trying to build on a different chain. Also user wallets with a lower EB setting will always be AD blocks behind the main tip.

My suggestion was, why not keep the sticky gate, except not for an unlimited blocksize, but only for a blocksize which has already occurred in the last 144 blocks. What is wrong with that, am I missing something obvious?

As for @theZerg 's suggestion. In my view the supporters of BU often have a view similiar to "Core should simply increase the blocksize limit, Core are making the issue more complicated than it is, as an unecessary distraction, to avoid a simple blocksize limit increase". I think @theZerg 's suggestion is very complicated and will be very difficult to explain and sell to potential supporters of BU. It would also make running a Bitcoin wallet very complicated.

 

[adamstgbit]

@jonny1000

ya.... good luck pushing the idea that Core has the simpler / safer solution to scaling.
[doublepost=1483127533,1483126837][/doublepost]

only for a blocksize which has already occurred in the last 144 blocks. What is wrong with that, am I missing something obvious?

including that last blocks which are >EB? seems like an incomplete solution. thats all.

 

[freetrader]

This BUIP didn't get quorum and wasn't brought up in the subsequent voting round - I expected it to be made available for voting again, but it was closed.

On Slack, thezerg described his impression that this would be the standard procedure (BUIP is closed if not passed because no quorum). I don't think the Articles are clear on that point, but I would like to have this BUIP put back on the table for the upcoming voting round.

@solex, please advise if it can be re-opened or if I need to open a new BUIP with the exact same proposal (actually, maybe this could benefit from being turned into a "make it optional" proposal).

 

[solex]

@freetrader
I agree that a BUIP which did not reach quorum should be revivable at a later date. However, BUIP038 did reach it (16 votes vs. quorum of 11) but was voted down. In this case it would be clearer for historical purposes to create a new one and include the main proposal from BUIP038 with some amendments which justify it being raised again.

 

[freetrader]

Thanks @solex, you are of course correct. For some reason I had conflated the BUIP038 / BUIP041 stalemate with BUIP040 's lack of quorum.