Scp timeout short circuit v blocking fix

[MonsieurNicolas]

This PR supersedes #1786

It adds a few comments and tests to cover updating values of (p,p').
The actual code change is not necessary because of the logic at

stellar-core/src/scp/BallotProtocol.cpp

Lines 829 to 831 in b8e58b3

	if (areBallotsLessAndCompatible(ballot, *mPrepared))
	{
	continue;

(also current code would crash if we ever hit that case because we check in SCP invariants that p and p' are not compatible) - but out of clarity and paranoia, it doesn't really hurt to add the condition explicitly.

While working on this, I noticed an actual bug, fixed in the "short-circuiting logic..." commit:
this relates to the rule (9) in the SCP white paper where we should be evaluating any potential counter (greater than the current counter), to see if there is no v-blocking set that is passed that counter.

The previous code was bailing out if there were any validator on a smaller counter than the current counter.
Effect was that the node would stay longer in the current state, increasing consensus time, relying on timeout instead of observation from messages from other nodes.

[graydon]

So I think I agree with @jonjove that the effect of this change is (semantically) just to change the early break in the second loop of attemptBump from break to a continue. It took me a while to convince myself this is enough to implement the requirements of the paper / internet-draft, given the boundary conditions and the way the conditions are coded though.

In the process of deciding it was correct, I refactored and commented it a fair bit; if you'd like to pull in that change too, I've posted it here:

graydon@1aa9bc8

If you like I can file it as a subsequent cleanup PR later.

[graydon]

If this 3rd condition is over-paranoid rather than a condition we believe could ever occur, should it be an assertion?

[MonsieurNicolas]

there is already an assert as it would violate SCP invariants

[MonsieurNicolas]

cool, I added @graydon 's cleanup commit that makes it better. @jonjove r+ when you get a chance

[jonjove]

I think this should be strict inequality. By the time this line is reached, we have already determined (line 1392) that hasVBlockingSubsetStrictlyAheadOf(localNode, mLatestEnvelopes, localCounter) == true. Therefore the condition on line 1413 cannot be satisfied for n = localCounter, so it may as well be excluded from allCounters.

[MonsieurNicolas]

yes agree, fixed

[jonjove]

I don't think this is actually reachable. Suppose that there exists a v-blocking set strictly ahead of localCounter. Then there exists at least one element in mLatestEnvelopes with counter c > localCounter, because the empty set is not a v-blocking set. Therefore allCounters contains a counter c > localCounter; specifically allCounters is not empty. Now fix the highest counter C in allCounters. If there does not exist a v-blocking set strictly ahead of C, then this line cannot be reached and we are done. Suppose instead that there does exist a v-blocking set strictly ahead of C. Then, as before, there exists at least one element in mLatestEnvelopes with counter c > C, because the empty set is not a v-blocking set. But this implies that allCounters includes c > C, which contradicts that C is the highest counter in allCounters.

[MonsieurNicolas]

I agree, this comment and assert are confusing, I am removing them. I could have put an assert(false) here but this doesn't seem to meet the bar for crashing consensus

[jonjove]

r+ b943785

[choza13]

thanks Pada tanggal Rab, 6 Feb 2019 pukul 05.25 Latobarita < notifications@github.com> menulis:

…

Merged #1935 <#1935> into master. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1935 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AtBCEmlZj3nNcr1JeI0P9jpLDj44K9A1ks5vKgTagaJpZM4aZUl4> .