diff --git a/zip-XXX-light-payment-detection.rst b/zip-XXX-light-payment-detection.rst index bc84c37a..d274d21e 100644 --- a/zip-XXX-light-payment-detection.rst +++ b/zip-XXX-light-payment-detection.rst @@ -1,11 +1,12 @@ :: - ZIP: XXX + ZIP: 307 Title: Light Client Protocol for Payment Detection Authors: George Tankersley Jack Grigg Credits: Matthew Green Category: Standards Track + Status: Draft Created: 2018-09-17 License: MIT @@ -68,8 +69,7 @@ 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. Methods for weakening this assumption are -discussed in appendix FOO. +faithfully transmit queries and responses. This ZIP does not address how to spend notes privately. @@ -91,7 +91,7 @@ A **compact block** is a packaging of ONLY the data from a block needed to: 3. Update your witnesses to generate new Sapling spend proofs. A compact block and its component compact transactions are encoded on the wire using the -following Protocol Buffers [XXX] format: +following Protocol Buffers [#protocolbuffers] format: .. code:: proto @@ -136,7 +136,7 @@ Output Compression ------------------ In the normal Zcash protocol, the output ciphertext consists of the AEAD encrypted form of -a *note plaintext* [Note]: +a *note plaintext* [#protocol-notept]_: +------------+----------+----------+-------------+-----------------------------------+ | 8-bit 0x01 | 88-bit d | 64-bit v | 256-bit rcm | memo (512 bytes) + tag (16 bytes) | @@ -170,7 +170,7 @@ and spendable. Spend Compression ----------------- -Recall that a full Sapling Spend description is 384 bytes long [Spend]: +Recall that a full Sapling Spend description is 384 bytes long [#protocol-spendencoding]: +-------+--------------+-----------+ | Bytes | Name | Type | @@ -257,7 +257,7 @@ Scanning for relevant transactions For every ``CompactOutput`` in the ``CompactBlock``, the light client can trial-decrypt it against a set of Sapling incoming viewing keys. The procedure for trial-decrypting a ``CompactOutput`` (*cmu*, *epk*, *ciphertext*) with an incoming viewing key *ivk* is a -slight deviation from the standard decryption process [#sapling-ivk-decryption]_: +slight deviation from the standard decryption process [#protocol-saplingdecryptivk]_: - let sharedSecret = KA\ :sup:`Sapling`\ .Agree(*ivk*, *epk*) - let K\ :sup:`enc` = KDF\ :sup:`Sapling`\ (sharedSecret, *epk*) @@ -274,11 +274,11 @@ Creating and updating note witnesses As ``CompactBlocks`` are received in height order, and the transactions within them have their order preserved, the *cmu* values in each ``CompactOutput`` can be sequentially appended to an incremental Merkle tree of depth 32 in order to maintain a local copy of -the Sapling note commitment tree. [#sapling-commitment-tree]_ This can then be used to +the Sapling note commitment tree. [#protocol-merkletree]_ This can then be used to create incremental witnesses for each unspent note the light client is tracking. [#incremental-witness]_ An incremental witness updated to height ``X`` corresponds to a Merkle path from the note to the Sapling commitment tree anchor for block ``X``. -[#sapling-merkle-path]_ +[#protocol-merklepath]_ Let ``tree`` be the Sapling note commitment tree at height ``X-1``, and ``note_witnesses`` be the incremental witnesses for unspent notes detected up to height ``X-1``. When the @@ -341,13 +341,15 @@ validation. If a txid is used in a ``GetTransaction`` call, the returned transac SHOULD be checked against the corresponding ``CompactOutputs``, in addition to verifying the transaction signatures. -[**TODO:** Do we want the next paragraph here?] +Potential extensions +```````````````````` A trivial extension (with corresponding bandwidth cost) would be to transmit empty ``CompactTxs`` corresponding to transactions that do not contain Sapling spends or outputs. A more complex extension would send the inner nodes within the transaction trees corresponding to non-Sapling-relevant subtrees; this would require strictly less -bandwidth that the trivial extension. +bandwidth that the trivial extension. These extensions are not currently defined. + Client-server interaction ------------------------- @@ -571,10 +573,6 @@ uninteresting transactions as well, and SHOULD download all transactions in any which a single full transaction is fetched (interesting or otherwise). It MUST convey to the user that fetching full transactions will reduce their privacy. -Appendix FOO -============ - -You can require the proxy to give you all the block headers to validate. Reference Implementation ======================== @@ -582,31 +580,17 @@ Reference Implementation This proposal is supported by a set of libraries and reference code made available by the Zcash Company. -[NOTE: 2018-09-17 WE HAVE NOT YET FINISHED OR RELEASED THESE.] References ========== .. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ - -[ZEC] Zcash Protocol Spec - -[bipXXX] define a light client - -[XXX] protobufs - -[Note] [ZEC] Section 5.5 - -[Spend] [ZEC] Section 7.x - -[Output] [ZEC] Section 7.x - -.. [#sapling-ivk-decryption] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2018.0-beta-31 or later [Overwinter+Sapling] `_ - -.. [#sapling-commitment-tree] `Section 3.7: Note Commitment Trees. Zcash Protocol Specification, Version 2018.0-beta-32 or later [Overwinter+Sapling] `_ - +.. [#protocol-merkletree] `Section 3.7: Note Commitment Trees. Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocol-merklepath] `Section 4.8: Merkle Path Validity. Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocol-saplingdecryptivk] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocol-notept] `Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocol-spendencoding] `Section 7.3: Encoding of Spend Descriptions. Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocol-outputencoding] `Section 7.4: Encoding of Output Descriptions. Zcash Protocol Specification, Version 2020.1.6 `_ +.. [#protocolbuffers] `Protocol Buffers. `_ .. [#incremental-witness] `TODO` - -.. [#sapling-merkle-path] `Section 4.8: Merkle path validity. Zcash Protocol Specification, Version 2018.0-beta-32 or later [Overwinter+Sapling] `_ - .. [#spv-clients] `TODO`