That's cool. We are too. But are you aware of the technical issues here? If you wish a "anonymizer" in your chainblock. Wee're working on another "anonymizer" implementation as well. This will not require changes to the chainblock, but would require all users to download a updated wallet. If you would like to discuss it more please PM me.
DigitalHermit did a great job highlighting the biggest flaw with the implementations yet.
FYI:
how far is your zerocoin implementation?
Was just coming here to ask the same thing. Any updates?
It's still in an early stage. The first part will be implementing the early alpha of Zerocoin into the Anoncoin testnet, then comes the testing to discover bugs within Zerocoin itself that the Zerocoin devs will be working on. I would not expect a fully working zerocoin implementation until the end of the year at best. If it works flawlessly the first time around (personally I believe there's a ~1% chance of that happening) it would probably be complete during november.
Are you integrating the Zerocoin v1 library as is or do you have plans to deal with the two major flaws in Zerocoin first, before releasing it for use against the "production" AnonCoin blockchain?
Flaw #1: Zerocoin v1 is highly inefficient (not production ready).
https://github.com/Zerocoin/libzerocoin/wiki/Frequently-asked-questionsThe current implementation of Zerocoin has two efficiency problems. First, the 'coin spend' zero knowledge proofs are somewhat large (>25 KB). We intend for these proofs to reside in the block chain, but their large size makes this challenging. As a result it may be necessary to distribute them via some other mechanism such as a Distributed Hash Table.
Additionally, Zerocoin spend proofs are somewhat time consuming to verify, at least as compared to ECDSA signatures (they take a larger fraction of a second). This creates problems with latency when all nodes verify them, though we are hopeful that there are engineering solutions to this problem.
We are currently working on improvements to the Zerocoin cryptography that we hope will bring smaller and faster proofs. At this point we will release a 'Zerocoin v2' protocol and users will have to decide if they want to deploy this protocol in their networks.
Flaw #2: Zerocoin as currently implemented requires configuration with a trusted non-secret integer of 1,026 bits in length generated by multiplying together two factors p and q. That means you need a "trusted party" to configure Zerocoin; more importantly, if this trusted party decides to hold on to the p and q factors they used (rather than destroying them) or shares them with anybody, then they will be able to double spend any zerocoins. This is a
fatal flaw if we wish Zerocoin to operate in a zero-trust manner.
https://github.com/Zerocoin/libzerocoin/wiki/Generating-Zerocoin-parametersSecurity Warning: It is critical that the modulus N be generated properly and that the factors p, q and all related information be destroyed. These factors are not needed in the protocol. Moreover, any party who learns these factors will be able to double-spend zerocoins. Note however that knowledge of p, q does not jeopardize the anonymity of Zerocoin.
...
A second project (not currently planned) is to implement distributed multiparty generation of the modulus N. Some protocols exist in the literature to do this. We are not aware of any that have been implemented.
If you plan on integrating Zerocoin as is, that's fine. I just hope you realize that by doing so you'll be turning the AnonCoin blockchain into more of a test/research blockchain that may not scale well (due to Flaw 1) and can't be fully trusted (due to Flaw 2).
;
