From 3a72b4cf604cc0fc70c5ac839e45052abfc99cd2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 16 Oct 2020 03:04:30 +0100 Subject: [PATCH] ZIP 307: cosmetics. Signed-off-by: Daira Hopwood --- zip-0307.html | 8 ++++---- zip-0307.rst | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/zip-0307.html b/zip-0307.html index e4002da8..a70bd924 100644 --- a/zip-0307.html +++ b/zip-0307.html @@ -22,7 +22,7 @@ License: MIT

The terms below are to be interpreted as follows:

Light client
-
A client that is not a full participant in the network of Zcash peers. It can send and receive payments, but does not store or validate a copy of the blockchain.
+
A client that is not a full participant in the network of Zcash peers. It can send and receive payments, but does not store or validate a copy of the block chain.

Abstract

@@ -35,7 +35,7 @@ License: MIT

There are three logical components to a Zcash light client system:

  • Zcash node that provides chain state and serves as a root of trust for the system.
    • -
  • Proxy server that extracts blockchain data from zcashd to store and serve it in a lower-bandwidth format.
    • +
  • Proxy server that extracts block chain data from zcashd to store and serve it in a lower-bandwidth format.
  • Light client that subscribes to the stream from a proxy server and uses that data to update its own view of the chain state. The light client MAY be attached to a wallet backend that will track particular Sapling notes.
@@ -44,7 +44,7 @@ License: MIT

Security Model

-

In this model, we propose payment detection privacy as our main security goal. That is, the proxy should not learn which transactions (received from the blockchain) are addressed to a given light wallet. If we further assume network privacy (via Tor or similar), the proxy should not be able to link different connections or queries as deriving from the the same wallet.

+

In this model, we propose payment detection privacy as our main security goal. That is, the proxy should not learn which transactions (received from the block chain) are addressed to a given light wallet. If we further assume network privacy (via Tor or similar), the proxy should not be able to link different connections or queries as deriving from the the same wallet.

In particular, the underlying Zcash node / proxy combination is assumed to be "honest but curious" and is trusted to provide a correct view of the current best chain state and to faithfully transmit queries and responses.

This ZIP does not address how to spend notes privately.

@@ -89,7 +89,7 @@ License: MIT

The output and spend descriptions are handled differently, as described in the following sections.

Output Compression

-

In the normal Zcash protocol, the output ciphertext consists of the AEAD encrypted form of a note plaintext 5:

+

In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a note plaintext 5:

diff --git a/zip-0307.rst b/zip-0307.rst index f6c17ba1..b59dce7c 100644 --- a/zip-0307.rst +++ b/zip-0307.rst @@ -22,7 +22,7 @@ The terms below are to be interpreted as follows: Light client A client that is not a full participant in the network of Zcash peers. It can send and - receive payments, but does not store or validate a copy of the blockchain. + receive payments, but does not store or validate a copy of the block chain. Abstract ======== @@ -46,7 +46,7 @@ There are three logical components to a Zcash light client system: - **Zcash node** that provides chain state and serves as a root of trust for the system. -- **Proxy server** that extracts blockchain data from zcashd to store and serve it in a +- **Proxy server** that extracts block chain data from zcashd to store and serve it in a lower-bandwidth format. - **Light client** that subscribes to the stream from a proxy server and uses that data to @@ -63,7 +63,7 @@ Security Model ============== In this model, we propose **payment detection privacy** as our main security goal. That -is, the proxy should not learn which transactions (received from the blockchain) are +is, the proxy should not learn which transactions (received from the block chain) are addressed to a given light wallet. If we further assume network privacy (via Tor or similar), the proxy should not be able to link different connections or queries as deriving from the the same wallet. @@ -136,7 +136,7 @@ sections. Output Compression ------------------ -In the normal Zcash protocol, the output ciphertext consists of the AEAD encrypted form of +In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a *note plaintext* [#protocol-notept]_: +------------+----------+----------+---------------+-----------------------------------+