BUIP038: (closed) Revert "sticky gate"

Discussion in 'Bitcoin Unlimited' started by dgenr8, Nov 27, 2016.

  1. dgenr8

    dgenr8
    Expand Collapse
    Member

    Joined:
    Sep 18, 2015
    Messages:
    47
    Likes:
    78
    > 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?
     
  2. theZerg

    theZerg
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 28, 2015
    Messages:
    829
    Likes:
    1,798
    what are you even talking about? How does my simple statement of the current behavior when under your attack imply any of those things?
     
    Collapse Signature Expand Signature
  3. awemany

    awemany
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 19, 2015
    Messages:
    1,084
    Likes:
    3,649
    Sure. It is simply ($738/BTC) * (12.5 BTC) * K / p.
     
  4. theZerg

    theZerg
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 28, 2015
    Messages:
    829
    Likes:
    1,798
    I meant all the math...
     
    Collapse Signature Expand Signature
    awemany likes this.
  5. awemany

    awemany
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 19, 2015
    Messages:
    1,084
    Likes:
    3,649
    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.
     
  6. freetrader

    freetrader
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Dec 16, 2015
    Messages:
    1,853
    Likes:
    4,713
    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.
    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.
     
    #26 freetrader, Nov 30, 2016
    Last edited: Nov 30, 2016
  7. dgenr8

    dgenr8
    Expand Collapse
    Member

    Joined:
    Sep 18, 2015
    Messages:
    47
    Likes:
    78
    @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.
     
  8. theZerg

    theZerg
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 28, 2015
    Messages:
    829
    Likes:
    1,798
    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.
     
    Collapse Signature Expand Signature
  9. freetrader

    freetrader
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Dec 16, 2015
    Messages:
    1,853
    Likes:
    4,713
    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?
     
    Peter R likes this.
  10. theZerg

    theZerg
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 28, 2015
    Messages:
    829
    Likes:
    1,798
    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.
     
    Collapse Signature Expand Signature
    Norway and awemany like this.
  11. awemany

    awemany
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 19, 2015
    Messages:
    1,084
    Likes:
    3,649
    @theZerg: Also good points, the more I think about this, the more I feel miner input wouldn't be bad on this issue.

    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.
     
  12. freetrader

    freetrader
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Dec 16, 2015
    Messages:
    1,853
    Likes:
    4,713
    @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.
     
    Mengerian likes this.
  13. solex

    solex
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 22, 2015
    Messages:
    1,028
    Likes:
    3,371
    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...?
     
    Collapse Signature Expand Signature
    Norway, Mengerian and awemany like this.
  14. awemany

    awemany
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 19, 2015
    Messages:
    1,084
    Likes:
    3,649
    @solex: Thanks. I like that idea of a flag - keeps with BU's spirit of striving for unlimited configurability.
     
  15. Roy Badami

    Roy Badami
    Expand Collapse
    Member

    Joined:
    Dec 27, 2015
    Messages:
    92
    Likes:
    117
    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.
     
  16. dgenr8

    dgenr8
    Expand Collapse
    Member

    Joined:
    Sep 18, 2015
    Messages:
    47
    Likes:
    78
    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.


    The change was a mistake. Surely you can admit this is a possibility?
    --- Double Post Merged, Dec 2, 2016 ---
    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?
     
  17. Peter Tschipper

    Peter Tschipper
    Expand Collapse
    Active Member

    Joined:
    Jan 8, 2016
    Messages:
    241
    Likes:
    337
    reddit:
    BitsenBytes
    @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.
     
  18. solex

    solex
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 22, 2015
    Messages:
    1,028
    Likes:
    3,371
    @dgenr8 No reason for delay :) Added to index now.
     
    Collapse Signature Expand Signature
    Norway and Peter R like this.
  19. theZerg

    theZerg
    Expand Collapse
    Moderator
    Staff Member

    Joined:
    Aug 28, 2015
    Messages:
    829
    Likes:
    1,798
    Yes, that's what happens today. The gate is only open on the large block chain...
    --- Double Post Merged, Dec 2, 2016 ---
    @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.

    (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.
     
    Collapse Signature Expand Signature
    #39 theZerg, Dec 2, 2016
    Last edited: Dec 2, 2016
    Norway likes this.
  20. dgenr8

    dgenr8
    Expand Collapse
    Member

    Joined:
    Sep 18, 2015
    Messages:
    47
    Likes:
    78
    @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.