BUIP038: (closed) Revert "sticky gate"

[dgenr8]

> But after a certain period, things will simply revert back to normal unless the attacker continues to waste his resources in this attack.

Does this mean you are withdrawing your proposal to automatically raise the node's EB setting after a single AD event? Does it also imply that you expect nodes NOT to modify their EB/AD setting in the 144 block sticky period after an event? If so, what is the point of the sticky period in the first place?

 

[theZerg]

what are you even talking about? How does my simple statement of the current behavior when under your attack imply any of those things?

 

[awemany]

can you share your math?

Sure. It is simply ($738/BTC) * (12.5 BTC) * K / p.

 

[theZerg]

I meant all the math...

 

[awemany]

Ah! Sorry. I linked a gist above: https://gist.github.com/awemany/d9d2eb0eb17c4c51b896df13fbfd0def

That gist includes python code. The simplest method to arrive at the probability is basically just subtracting two binomial CDFs. (I just sum the binomial PDF)

I compared @dgenr8's and my numbers - they match when accounting for the first excessive block. I then used the above formula to add the price.

 

[freetrader]

How does someone executing this attack result in a fork? BU will either incorporate the huge block into the blockchain, or orphan it.

The fork in question here, as I understood dgenr8's post, was the fork from < 1MB blocks to a chain including a >1MB block + a (perhaps temporary) majority of BU hashpower, not a temporary chain fork during the sketched attack.

Attackers could temporarily increase the typically accepted block size and drive a few large blocks onto the blockchain. But after a certain period, things will simply revert back to normal unless the attacker continues to waste his resources in this attack.

And then majority of nodes will simply increase their AD.

I question whether "things will simply revert back to normal".
For one, without experience of operating Bitcoin under emergent consensus, it is at least possible that such events will change the response of the network, by operators adjusting their EB and AD and potentially re-sticking this gate if they feel they want to.

It does not make sense to me that node operators / miners would not take some action if they were to see an excessive block with some unknown power piling enough work on to it to risk subjecting the network to an "any size goes" situation for the next 144 blocks.

 

[dgenr8]

@theZerg We should probably find a way to communicate more high-bandwidth.

I'm saying that stickiness can only lower the bar significantly for causing the network to start accepting larger blocks than before. I have not seen this mentioned so I thought it might be an unintended consequence.

 

[theZerg]

Yes it is unintended, and I don't think that its practical or efficacious. But I do agree that theoretical attacks should be prevented.

This is why I am proposing the effective excessive block solution.

I do not think that reverting this fix is deployable by miners since the amount of money that could be lost is unbounded if the miner's EB is lower than the typical block being mined on the longest chain.

 

[freetrader]

Getting their EB cracked should be a serious event for a miner. IMO it necessitates a business decision (stay with current settings [what this BUIP proposes], adapt them (*), open the gate for a certain number of blocks etc).

(*) and here one could come up with any number of different approaches, suggesting it might be better left up to miners to implement their own policies. We dislike bikeshedding, right?

 

[theZerg]

I have to admit that you guys are driving me slightly nuts here.

Yes of course getting the EB cracked should necessitate a business decision. But the question is what should we do in the mean time?

If there is one thing that BU has always claimed is that it will ultimately switch to the most difficult chain, provided that rules that protect the money function are not broken. This is how we've been advertising to node operators for the last year: "install BU now so your node will follow consensus no matter what happens with the blocksize, sigops, etc".

But endlessly trailing the tip (especially for miners) is not really maintaining consensus -- nor is it forking. Its something in between.

So with this reversion, we won't have consensus -- instead we'll have nodes always AD blocks behind the chain. That behavior will be absolutely no use to a miner since all his blocks will be orphaned. So we might as well just assert() when the EB is broken -- at least we'll get the miner's attention!

And even worse, different miners will be mining on different forks depending on their AD value, (one will always mine 4 blocks from the tip, one 5, one 6, etc) so you could imagine a situation where small block miners regain the majority yet are dispersed on separate forks. This would have the exact same outcome as the "opening the gate" case -- it would allow a minority of "attacker" miner on the tip to create any block size, since they are the effective majority.

But if a miner WANTS to resist a large block chain until a business decision can be made, the BU solution is easy: just set AD to 99999.

You can follow similar reasoning for an exchange or any other type of node. There is no reason I can conceive of to endlessly trail the chain tip for any full node application that I know of.

But there are tremendous drawbacks for miners in terms of lost revenue, and its inconvenient for exchanges, etc.


When a problem is discovered, the solution is not to revert a change. The solution is to move forward with a fix for the problem.

 

[awemany]

@theZerg: Also good points, the more I think about this, the more I feel miner input wouldn't be bad on this issue.

So we might as well just assert() when the EB is broken -- at least we'll get the miner's attention!

I think that is a good idea in any case. The local EB being broken should make some noise IMO.


Not wanting to further increase the bikeshedding rate here, but this issue here could also be solved by adding an 'inacceptable block' setting, a block size the BU node will reject no matter what. Without changing the rest of the code.

The default setting for that I'd then put at infinity. So it doesn't change anything unless you tweak this value.

 

[freetrader]

@awemany : I don't think there is a policy here that fits all.

As a miner, any persistent failure to follow the majority of the network's consensus will result in "unbounded loss". Throwing an assert() accomplishes that just as well as endlessly trailing the tip, the only difference is someone might notice, i.e. avoidance of undetected failure.

@theZerg: Assuming a miner or significant economic node operator would endlessly trail the tip implies they never reached awareness of the situation, i.e. the "failure to remain within the green zone of consensus" remains undetected for a long time. That seems pretty far-fetched to me, given that they have real money at stake.

I think this is where BU can and should focus its initial efforts, rather than developing algorithmic solutions which turn out to be band aids because they don't allow users to express what could essentially be diverse and conflicting strategies.

Some suggestions:
- modal dialog window displaying warning message in GUI, plus some sort of warning icon in status bar when there is a "more-work" chain that is being suppressed by your EB/AD settings ("trailing the tip")
- log messages when trailing the tip - e.g. IN CAPITAL LETTERS, on reception of every block
- user option to automatically shutdown the software when EB is cracked (imo this is not a very user-friendly way to handle policy updates, but it may be ok for a start while better ways are developed)

I think the biggest problem is that miners and node operators don't have a clear idea right now of "what must I do now?" when their EB setting is exceeded, and a chief concern seems to be that they might not even realize they have to act.

 

[solex]

@solex: When is the next chance to vote on this BUIP?

Note that the spin from the Core team when the gate opens will be: See? BU has no blocksize limit now, you gave your soul to the devil...

We just passed a bunch of BUIPs, and Christmas is coming up so I was thinking about 1st week of January. We also want to avoid "vote fatigue" in the membership. Of course if there is a BUIP deemed to be urgent then we can certainly schedule a vote very quickly.

To be honest, the Developer has an open mandate to fix issues found in the software, and I imagine that this is wide enough to cover a known attack loophole. The problem here is that there is disagreement between some of the people most qualified to assess the risk, so while throwing this open to the membership may procedurally solve the problem, it may not advance the best technical solution.

What about a compromise solution where there is a "stickygate" argument added with default=OFF. Which means that this does not have to hold up the new point version release...?

 

[awemany]

@solex: Thanks. I like that idea of a flag - keeps with BU's spirit of striving for unlimited configurability.

 

[Roy Badami]

I'm probably missing something obvious but: shouldn't the sticky gate just automatically reset if/when it becomes clear that a chain that is entirely <=EB is substantially longer than any chain that contains blocks >EB?

i.e. in a world with EB=1, if we temporarily accept an excessive block, but then reorg back onto the Core chain, and the Core chain is clearly dominant (FSOV clearly dominant) - shouldn't we just clear the sticky gate and reset to how we were before the anomaly/attack.

 

[dgenr8]

So with this reversion, we won't have consensus -- instead we'll have nodes always AD blocks behind the chain.

Your language is too loose. The chain is what you're building. Being behind in confirming a specific EB is the definition of AD.

What stickiness does is, it only lets this happen once. In fact, "1" is another new constant you've introduced. Why not 2 or 3 times?

If a node's EB is being exceeded repeatedly, then either
1) The node set EB poorly given the current advertisements in coinbases. If he's not paying close attention, he should set a higher EB, or
2) A majority suddenly started producing larger blocks without announcing it in EB. Blindly following this kind of majority removes the reason to advertise EB in the first place

Stickiness weakens the EB/AD mechanism by simply failing to allow it to work.

When a problem is discovered, the solution is not to revert a change. The solution is to move forward with a fix for the problem.

The change was a mistake. Surely you can admit this is a possibility?
[doublepost=1480695503][/doublepost]

What about a compromise solution where there is a "stickygate" argument added with default=OFF. Which means that this does not have to hold up the new point version release...?

The outcome of that would be 90% better than doing nothing. However, it is yet another change to code that already hasn't been tested enough for its critical nature, so it's safer to go back to what was in use before March 8, 2016.

@solex Is there a reason BUIP038 has not been added to the BUIP index?

 

[Peter Tschipper]

@dgenr8 I understand your concerns but I don't share them. I think you are assuming every miner is going to be running with AD5? Miners are already signalling with EB1 AD6 , (although I think they should really be doing something like AD10 to prevent the sticky gate from opening)...when/if the gate opens then yes I agree , we should probably have the EB automatically increase to the largest new block size but that's easy enough to solve. I believe that would solve all your concerns but even so I don't see a big problem here.

Furthermore, once the sticky gate is triggered most miners would increase their EB anyway..only the very small ones that don't watch the chain as closely would be subject to the larger block scenario you described, but those blocks would be quickly orphaned by the other miners which wouldn't be accepting those blocks. I really don't see any major concern about security here other than we should be automatically increasing the EB once the gate is triggered. Simple enough to fix and one @theZerg is aware of.

 

[solex]

@dgenr8 No reason for delay Added to index now.

 

[theZerg]

I'm probably missing something obvious but: shouldn't the sticky gate just automatically reset if/when it becomes clear that a chain that is entirely <=EB is substantially longer than any chain that contains blocks >EB?

i.e. in a world with EB=1, if we temporarily accept an excessive block, but then reorg back onto the Core chain, and the Core chain is clearly dominant (FSOV clearly dominant) - shouldn't we just clear the sticky gate and reset to how we were before the anomaly/attack.

Yes, that's what happens today. The gate is only open on the large block chain...
[doublepost=1480716997][/doublepost]@dgenr8 and @freetrader, if you are through evaluating my proposed revisions to your BUIP, I will issue my counter BUIP and open this up for general discussion (although I have been allowing other comments, technically I have the power to move them out of this thread until I agree to release the BUIP into general discussion or IIRC 2 weeks pass). I'll probably get my counter out and formally open general discussion early next week.

The change was a mistake. Surely you can admit this is a possibility?

(emphasis added) This comment is baiting, inappropriate and beneath you. I have already indicated why this change is extremely important, and proposed a compromise. Rather than address those reasons or the compromise idea, you have chosen to ignore them.

 

[dgenr8]

@solex Thank you

@Peter Tschipper AD=5 is just an example. Many were posting AD=4 when I looked. Automatically increasing local EB immediately when one excessive block is accepted would not solve my concerns at all. That is an even more significant lowering of the bar required for the network to accept larger blocks. One that a minority has a much greater chance of triggering.

@theZerg No need to get personal. You made a very strong statement that seemed to imply undoing a change was never the right solution. I question that.

I expressed strong, just not unqualified, support for @solex's compromise.