Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ZIP 307] Light Client Protocol for Payment Detection #226

Open
wants to merge 10 commits into
base: master
from

Conversation

@str4d
Copy link
Contributor

str4d commented Apr 11, 2019

gtank and others added 10 commits Oct 2, 2018
Client operations
Client updates
==========

Currently a client that wishes to send or receive shielded payments must be a full node
participanting in the Zcash network. This requires an amount of available bandwidth,

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

Suggested change
participanting in the Zcash network. This requires an amount of available bandwidth,
participating in the Zcash network. This requires an amount of available bandwidth,
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.

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

Suggested change
deriving from the the same wallet.
deriving from the same wallet.

A key observation in this protocol is that the current zcashd encrypted field is several
hundred bytes long, due to the inclusion of a transaction “memo”. The need to download
this entire field imposes a substantial bandwidth cost on each light wallets, which may be

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

Typo: "on each light wallets"

This comment has been minimized.

Copy link
@daira

daira Jul 31, 2019

Collaborator
Suggested change
this entire field imposes a substantial bandwidth cost on each light wallets, which may be
this entire field imposes a substantial bandwidth cost on each light wallet instance, which may be
this entire field imposes a substantial bandwidth cost on each light wallets, which may be
a limited mobile device on a restricted-bandwidth plan. While more efficient techniques
can be developed in the future, for the moment we propose ignoring the memo field during
payment detection. Futhermore, we can also ignore any information that is not directly

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

Suggested change
payment detection. Futhermore, we can also ignore any information that is not directly
payment detection. Furthermore, we can also ignore any information that is not directly
========================

This proposal is supported by a set of libraries and reference code made available by the
Zcash Company.

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

Zcash Company -> Electric Coin Company

This comment has been minimized.

Copy link
@daira

daira Jul 31, 2019

Collaborator
Suggested change
Zcash Company.
Electric Coin Company.
@@ -0,0 +1,612 @@
::

ZIP: XXX

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 12, 2019

ZIP: XXX -> ZIP: 307

This comment has been minimized.

Copy link
@daira

daira Jul 31, 2019

Collaborator
Suggested change
ZIP: XXX
ZIP: 307
@acityinohio

This comment has been minimized.

Copy link
Collaborator

acityinohio commented Apr 30, 2019

Concept ACK

@daira

This comment has been minimized.

Copy link
Collaborator

daira commented May 20, 2019

Concept ACK. This looks like it's not ready for merge yet (missing references, TODOs that should be resolved).


- let sharedSecret = KA\ :sup:`Sapling`\ .Agree(*ivk*, *epk*)
- let K\ :sup:`enc` = KDF\ :sup:`Sapling`\ (sharedSecret, *epk*)
- let P\ :sup:`enc` = ChaCha20.Decrypt\ :sub:`K^enc`\ (*ciphertext*)

This comment has been minimized.

Copy link
@daira

daira Jun 4, 2019

Collaborator

This is not specified precisely enough. The intent is to perform the decryption as it would be performed by IETF_AEAD_CHACHA20_POLY1305, but this involves decrypting with the block counter starting from 1. Since ChaCha20 is not defined at all, it's not clear that the block counter should start with 1.

I suggest adding a definition like this:

Let ChaCha20.Decrypt\ :sub:`K^enc`\ (*initialCounter*, *ciphertext*) be the
decryption of *ciphertext* with key K^enc, initial counter value *initialCounter*,
and all-zero nonce, as specified in section 2.4 of [#RFC7539]_.

and then use ChaCha20.DecryptK^enc(1, ciphertext).

@daira daira force-pushed the zcash:master branch 10 times, most recently from fff4d5c to f5af3a3 Aug 6, 2019
@daira daira force-pushed the zcash:master branch 5 times, most recently from 4864dde to c333fe2 Aug 6, 2019
@daira daira force-pushed the zcash:master branch from 0aef8ce to 2815bee Aug 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.