Re: [Din] draft-mazieres-dinrg-scp-04 page 15 settting prepared

[David Mazieres <[e-mail]>]

Piers Powlesland <[e-mail]> writes:

> Hi,
>
> The segment describing setting "prepared" on page 15 is as follows.
>
>>The highest accepted prepared ballot not exceeding the "ballot"
>>field, or NULL if no ballot has been accepted prepared.  Recall
>>that ballots with equal counters are totally ordered by the value.
>>Hence, if "ballot = <n, x>" and the highest prepared ballot is
>>"<n, y>" where "x < y", then the "prepared" field in sent messages
>>must be set to "<n-1, y>" instead of "<n, y>", as the latter would
>>exceed "ballot".
>
> I am wondering why the prepared counter must be set so that it does
> not exceed ballot as opposed to increasing the ballot counter so that
> ballot >= prepared?

If you increase the ballot counter, this messes up the timing.  SCP
depends on the fact that eventually all intact nodes will sit at the
same counter for sufficiently long to exchange a bunch of messages.
That in turn depends on starting a timer only when a quorum hits a
particular counter, and short-circuiting the timer and immediately
bumping the counter if you fall behind a blocking set.  If you add other
criteria for bumping the counter, you no longer have this property.
Also, the timeout lengthens with each counter, so you don't want to run
it up gratuitously.

> Also I can't see such a condition in the original SCP whitepaper, and
> I'm wondering if I have missed it or if this is a new addition to the
> balloting protocol?

It's new, because of the tweaks we needed to be able to end the
nomination protocol.  The whitepaper version assumed that nomination
continued in the background in perpetuity, which is not practical.  In
the whitepaper version, if you come online after a week of being off and
only have access to externalize messages, then even a v-blocking set of
externalize messages is not actionable if you are still stuck in the
balloting phase (you can't vote to confirm the highest confirmed
prepared ballot).

In general, where there are conflicts, the internet draft takes
precedence over the whitepaper.  We are actively working on the draft
and getting good feedback in response to implementation efforts.  Once
the draft stabilizes, we will have to go back and produce a revised
whitepaper.  Nothing we are doing should invalidate any of the proofs,
but we'll still need to update things.

David