biolizard89 wrote:The Zerocash team is working on a secure multiparty computation system for generating the public parameters, which mostly mitigates the trust issue.
So, question regarding Zerocash support in Namecoin... would it be a problem if name transactions had to be done via BaseNMC (address of owner is public), given that the BaseNMC that create a name can in turn be funded by ZeroNMC (address of owner not public)? The only problem I can see here is that if a name is atomically traded for NMC, the fact that a trade occurred would be public knowledge. I *think* the amount of the trade could be in ZeroNMC (but I'm not certain, since the protocol isn't public yet). If that's the case, then the default client could automatically generate an atomic trade transaction for all name_update transactions, so that would fix the issue as far as I can tell.
Thoughts?
So, I finally had a chance to fully read the Zerocash paper. Here's a snippet on how it's being integrated with an existing basecoin:
B. Integration by hybrid currency
A different approach is to extend Bitcoin with a parallel,
anonymized currency of “zerocoins,” existing alongside bit-
coins, using the same ledger, and with the ability to convert
freely between the two. The behavior and functionality of
regular bitcoins is unaltered; in particular, they may support
functionality such as scripting.
In this approach, the Bitcoin ledger consists of Bitcoin-style
transactions, containing inputs and outputs [20]. Each input is
either a pointer to an output of a previous transaction (as in plain
Bitcoin), or a Zerocash pour transaction (which contributes its
public value, v pub, of bitcoins to this transaction). Outputs
are either an amount and destination public address/script
(as in plain Bitcoin), or a Zerocash mint transaction (which
consumes the input bitcoins to produce zerocoins). The usual
invariant over bitcoins is maintained and checked in plain
view: the sum of bitcoin inputs (including pours’ v pub) must
be at least the sum of bitcoin outputs (including mints’ v),
and any difference is offered as a transaction fee. However,
the accounting for zerocoins consumed and produced is done
separately and implicitly by the DAP scheme.
So yeah, we don't even need to convert zerocoins into basecoins before creating a name transaction; the zerocoin pour operation acts as a standard transaction input, with the output being a basecoin name script.
For privacy purposes, all name_update transactions generated by the reference client should have 2 inputs: a basecoin input which corresponds to the name, and a zerocoin pour input which corresponds to an atomic payment. This makes it impossible to determine whether a name_update transaction is selling the name to a new owner (in exchange for zerocoins), or simply sending to the same owner (in which case the zerocoins are being sent to a change zerocoin address, minus the tx fee).
Also, there's an interesting section of the paper about scalability of the UTXO set:
Step 2: compressing the list of coin commitments.
In the above NP statement, CMList is specified explicitly as a list of
coin commitments. This naive representation severely limits
scalability because the time and space complexity of most
protocol algorithms (e.g., the proof verification algorithm)
grows linearly with CMList . Moreover, coin commitments
corresponding to already spent coins cannot be dropped from
CMList to reduce costs, since they cannot be identified (due to
the same zero-knowledge property that provides anonymity).
As in [3], we rely on a collision-resistant hash function CRH
to avoid an explicit representation of CMList. We maintain
an efficiently updatable append-only CRH -based Merkle tree
Tree (CMList) over the (growing) list CMList. Letting rt denote
the root of Tree (CMList), it is well-known that updating rt to
account for insertion of new leaves can be done with time and
space proportional to the tree depth. Hence, the time and space
complexity is reduced from linear in the size of CMList to
logarithmic. With this in mind, we modify the NP statement to
the following one: “I know r such that COMM r (sn) appears as
a leaf in a CRH-based Merkle tree whose root is rt”. Compared
with the naive data structure for CMList, this modification
increases exponentially the size of CMList which a given zk-SNARK
implementation can support (concretely, using trees of depth
64, Zerocash supports 2^64 coins).
So, unspent zerocoins aren't pruned by being spent, but instead the storage cost of the unspents set grows logarithmically (instead of linearly) with the number of unspents. I'm not sure how this compares to basecoins in practical terms, but it's a pretty cool setup.
As I read the Zerocash paper from beginning to end, I grew more and more impressed. These guys are awesome, they've thought of pretty much all the concerns I had.
@domob, what do you think about the above?
PS: As a sidenote, the paper is surprisingly readable. I skipped over the advanced math, but they have clear English descriptions of everything that they do, which are reasonably understandable for anyone with cursory knowledge in the subject. I would encourage everyone to read their paper, it's very cool stuff.