From 36d74b7f596b930bd11a13b5390ebba7fa464520 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Thu, 12 May 2022 16:47:20 +0200 Subject: [PATCH] PBTS: reference to v1 removed from algorithmic spec --- .../proposer-based-timestamp/pbts-algorithm_002_draft.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md index f2ec14036..915afbdc4 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md @@ -16,15 +16,10 @@ When a value `v` is produced by a process, it also assigns the associated propos If the same value `v` is then re-proposed in a subsequent round of consensus, it retains its original time, assigned by its original proposer. -A value `v` should re-proposed when it becomes locked by the network, i.e., when it receives `2f + 1 PREVOTES` in a round `r` of consensus. +A value `v` is re-proposed when it becomes a valid value, i.e., when it receives `2f + 1 PREVOTE`s in a round `r` of consensus. This means that processes with `2f + 1`-equivalent voting power accepted, in round `r`, both `v` and its associated time `v.time`. Since the originally proposed value and its associated time were considered valid, there is no reason for reassigning `v.time`. -In the [first version][algorithm_v1] of this specification, proposals were defined as pairs `(v, time)`. -In addition, the same value `v` could be proposed, in different rounds, but would be associated to distinct times each time it was reproposed. -Since this possibility does not exist in this second specification, the proposal time became part of the proposed value. -With this simplification, several small changes to the [arXiv][arXiv] algorithm are no longer required. - ## Time Monotonicity Values decided in successive heights of consensus must have increasing times, so: