[tor-commits] [torspec/master] other easier fixes to prop#280

[arma at torproject.org]

commit eb7c64b9bacd884b5e7b8b69f3caa614f01d8d86
Author: Roger Dingledine <arma at torproject.org>
Date:   Tue Sep 12 22:39:29 2017 -0400

    other easier fixes to prop#280
---
 proposals/280-privcount-in-tor.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/proposals/280-privcount-in-tor.txt b/proposals/280-privcount-in-tor.txt
index 716b48e..9b1a8b5 100644
--- a/proposals/280-privcount-in-tor.txt
+++ b/proposals/280-privcount-in-tor.txt
@@ -220,7 +220,7 @@ Status: Draft
        [Exactly once]
 
        The curve25519 public key of the tally reporter who is intended
-       to receive an decrypt this document.  The key is base64-encoded
+       to receive and decrypt this document.  The key is base64-encoded
        with padding stripped.
 
     "count-document-digest" SP "sha3" Digest NL
@@ -259,7 +259,7 @@ Status: Draft
   instance of that keyword's blinded counter.
 
   For example: if the count document lists the keywords "b", "x", "g",
-  and "a" (in that order), and lists instances "0", and "2", then the
+  and "a" (in that order), and lists instances "0" and "2", then the
   decrypted data will hold the blinding values in this order:
       b, instance 0
       b, instance 2
@@ -308,7 +308,7 @@ Status: Draft
 
 6. An optimized alternative
 
-   As an alternative, the sequences of blinding values is NOT transmitted
+   As an alternative, the sequences of blinding values are NOT transmitted
    to the tally reporters.  Instead the client generates a single
    ephemeral keypair sk_c, PK_c, and places the public key in its counts
    document.  It does this each time a new round begins.