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

David Mazieres <> Fri, 21 September 2018 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EE0C130EE1 for <>; Fri, 21 Sep 2018 11:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-5rJdv_FyqJ for <>; Fri, 21 Sep 2018 11:19:18 -0700 (PDT)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4918B130E42 for <>; Fri, 21 Sep 2018 11:19:18 -0700 (PDT)
Received: from (localhost []) by ( with ESMTP id w8LIJFD6067101; Fri, 21 Sep 2018 11:19:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=scs; t=1537553955; bh=QNTCFsgth6nBAaWLWwPrR+7RIRDedRxpMcetfkUTmAs=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=R7/Rx7/JYOTh9cPDe/8+pyDpLTla0FsHiUzMIwo74XoN7P566nT1R/aHoKxOSG6i1 PYUjtOXGygTvGng9eaGBChB8aXdzNrOvU9kUq7ZUaSVuLDhWntR+UUPqV05xy4l2wn KD2H04MxFzZnQRpU5HX4S/ArjAqet5yzqVV8PdzU=
Received: (from dm@localhost) by ( id w8LIJFfi093020; Fri, 21 Sep 2018 11:19:15 -0700 (PDT)
From: David Mazieres <>
To: Piers Powlesland <>,
In-Reply-To: <>
References: <>
Reply-To: David Mazieres expires 2018-12-20 PST <>
Date: Fri, 21 Sep 2018 11:19:15 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Din] draft-mazieres-dinrg-scp-04 page 15 settting prepared
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2018 18:19:21 -0000

Piers Powlesland <> 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.