Hi Antoine,

Thank you for your comments. They are touching on some of the key aspects of the
protocol.

> in this proposed CSV scheme it sounds each nullifier verification participant
> needs the banwidth cost to read the whole of the blockchain.

You're correct. Shielded CSV nodes need to have access to the current best
blockchain, similar to regular Bitcoin nodes. Shielded CSV nodes scan for
64-byte nullifiers, verify their half-aggregate signatures and place them in a
data structure we call "nullifier accumulator".

There's potential for a light client scheme, where users don't validate blocks,
but infer the best blockchain via proof-of-work (similar to SPV) and obtain the
corresponding nullifier accumulator value from somewhere. In addition, they
receive a succinct proof that the blockchain is valid and the nullifier
accumulator value is correct.

This model allows the light client to receive transactions. However, to create
transactions, they need to prove inclusion in the nullifier accumulator, which
requires knowledge of the nullifiers in the blockchain. There are some ideas for
how to do this in a relatively light fashion, but nothing concrete yet. It's
certainly an interesting area for further exploration.

> there could be a way to hide the coin creation time

A coin (the data sent to the recipient) contains the exact location of the
nullifier that created the coin. This is indeed a noteworthy issue and we
discuss the implications in section 6.3 of the paper. In particular, revealing
the nullifier location implies that outputs of the same transaction are
linkable. We therefore suggest that regular wallets should just create a single
output.

A fundamental limitation of the Shielded CSV model appears to be that the sender
must reveal an upper bound on when the coin has been created ("This coin is
older than the block at height..."). Otherwise, the receiver would not know how
long to wait until the coin has sufficient confirmations.

In fact, a previous version of the Shielded CSV protocol did exactly that. But
we moved away from that because it was incompatible with our ideas to support
pruning the wallet state (i.e., removing old transaction history), which is an
important aspect in holistic privacy.

We came up with a version of the protocol that supported prunable wallet state
and only leaked the block in which the coin was created and not the exact
nullifier. However, this version has two drawbacks:
1. The state the wallet needs to keep for the unpruned transaction history is
larger: 256 bits per received coin (one hash) instead of about 60 bits (the
blockchain location).
2. The privacy improvement is fuzzy and difficult to understand. In the extreme
case, such as when there's only one nullifier in the block, there's no
improvement over the current Shielded CSV version.

But I agree, if possible without significant drawbacks, this privacy leak should
be mitigated.