zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 307: cosmetics. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-10-16 03:04:30 +01:00
parent e63f046675
commit 3a72b4cf60
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
zip-0307.html
View File

@ -22,7 +22,7 @@ License: MIT</pre>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Light client</dt>
<dd>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.</dd>
<dd>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.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -35,7 +35,7 @@ License: MIT</pre>
<p>There are three logical components to a Zcash light client system:</p>
<ul>
<li><strong>Zcash node</strong> that provides chain state and serves as a root of trust for the system.</li>
<li><strong>Proxy server</strong> that extracts blockchain data from zcashd to store and serve it in a lower-bandwidth format.</li>
<li><strong>Proxy server</strong> that extracts block chain data from zcashd to store and serve it in a lower-bandwidth format.</li>
<li><strong>Light client</strong> 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.</li>
</ul>
<figure class="align-center" align="center">
@ -44,7 +44,7 @@ License: MIT</pre>
</figure>
</section>
<section id="security-model"><h2><span class="section-heading">Security Model</span><span class="section-anchor"> <a rel="bookmark" href="#security-model"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In this model, we propose <strong>payment detection privacy</strong> 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.</p>
<p>In this model, we propose <strong>payment detection privacy</strong> 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.</p>
<p>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.</p>
<p>This ZIP does not address how to spend notes privately.</p>
</section>
@ -89,7 +89,7 @@ License: MIT</pre>
<p>The output and spend descriptions are handled differently, as described in the following sections.</p>
</section>
<section id="output-compression"><h3><span class="section-heading">Output Compression</span><span class="section-anchor"> <a rel="bookmark" href="#output-compression"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD encrypted form of a <em>note plaintext</em> <a id="id2" class="footnote_reference" href="#protocol-notept">5</a>:</p>
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a <em>note plaintext</em> <a id="id3" class="footnote_reference" href="#protocol-notept">5</a>:</p>
<table>
<tbody>
<tr>

8
zip-0307.rst
View File

@ -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]_:
+------------+----------+----------+---------------+-----------------------------------+