He claims to have fixed every problem with zerocoin, which is simple not believable. The binary could be full of backdoors, even if we had the source code it woudl take some time to determine whether the coin is safe.
assuming the OP is even a vtc dev, it would be suicidal to fork vtc to include zerocoin, zerovert's implementation will most probably not work properly anyway, zerocoin is a work in progress with known flaws.
Right, not a fork. This is a new coin that stands on its own.
It does work. We have done thorough testing. Would be happy to answer any questions you might have
Thank you! I'm glad it works if it truly does
- What would the blockchain size for zerovert be if it was vertcoin for example? (same amount of time going now, same amount of transactions)
- how long does it take to create an average tx you can find on the vertcoin network right now (same avg inputs, depth..),
- same but how long to confirm?
(I'm using vertcoin as the benchmark since you should be familiar with the current metrics and it's a more or less successful alt with some volume.)
- so, in general, how much more space/bandwidth or cpu power than a btc transaction do you need? (zerocoin is many times more)
- zerocoins have to be all the same face value, how are you addressing that? a few different zerocoin types? just one? your thoughts on the constraints either choice implies
- are you basing your work on
https://github.com/Zerocoin/libzerocoin ?
- Address these issues:
http://en.wikipedia.org/wiki/Zerocoin#Criticism- Are you improving any aspects of zerocoin in the same way as zerocash? if so, what exactly?
- Are you improving any aspects of the original zerocoin in other ways? in what ways exactly?
- No pool or exchange will run your closed-source client in their servers, even less so given that you are unknown/id unproven so far. How do you plan on making people adopt your coin with closed source.
- What would the blockchain size for zerovert be if it was vertcoin for example? (same amount of time going now, same amount of transactions)
Almost the same. Only difference is the accumulator which is less than a kb per block
- how long does it take to create an average tx you can find on the vertcoin network right now (same avg inputs, depth..),
The act of creating an average tx is nearly the same (createrawtransaction, signrawtransaction, sendrawtransaction each under a second).
- same but how long to confirm?
(I'm using vertcoin as the benchmark since you should be familiar with the current metrics and it's a more or less successful alt with some volume.)
less than a minute
- so, in general, how much more space/bandwidth or cpu power than a btc transaction do you need? (zerocoin is many times more)
Space - not much more actually, we use an incremental accumulator that is A = u^(c1 * c2 * c3... * cn) mod n. So accumulator is less than a kb.
Cpu power, not a lot more either. We'll do some more performance testing to see compare to bitcoin later on.
- zerocoins have to be all the same face value, how are you addressing that? a few different zerocoin types? just one? your thoughts on the constraints either choice implies
One for now, we will eventually integrate support for multiple denominations
- are you basing your work on
https://github.com/Zerocoin/libzerocoin ?
A bit of it
- Address these issues:
http://en.wikipedia.org/wiki/Zerocoin#CriticismStored outside of blockchain, with RSA modulus from world renowned RSA factoring challenge of unknown factorization. Computational time is very reasonable in comparison to bitcoin
- Are you improving any aspects of zerocoin in the same way as zerocash? if so, what exactly?
We're investigating a lot of different possible improvements. If you can ask about specific improvements, I'll be better suited to answer. Not all improvements are possible with zerocoin though.
- Are you improving any aspects of the original zerocoin in other ways? in what ways exactly?
Using the RSA modulus from world renowned RSA factoring challenge of unknown factorization
- No pool or exchange will run your closed-source client in their servers, even less so given that you are unknown/id unproven so far. How do you plan on making people adopt your coin with closed source.
Not sure if that's true
Right, but can you explain how you did the trustless setup to establish the accumulator? And also what trustless entities exactly were included in the setup, as right now it's impossible to verify that anyone except you has generated the accumulator? That's a rather important point as it would allow you to spend anyone's money otherwise, without anyone possibly being able to tell it was you doing so. It seems confusing to me how you possibly got the niZKP down to a reasonable size and verification time, too, for instance they're 128-256 kb in the default implementation, with verification times of 4 or more seconds each.
The accumulator requires an RSA modulus of unknown factorization, so we used the RSA modulus of unknown factorization from the world renowned RSA factoring challenge.
We implement zerocoin, not zerocash. And yes, we said generating transaction is less than a second, with verification time less than a minute
The accumulator requires an RSA modulus of unknown factorization, so we used the RSA modulus of unknown factorization from the world renowned RSA factoring challenge.
We implement zerocoin, not zerocash. And yes, we said generating transaction is less than a second, with verification time less than a minute
There's only a handful of even modestly secure primes p and q from that list, from 1536-bits to 2048-bits, with which to use to get N = pq. Key lengths of 2048 bits are unlikely to be secure within the next 5-15 years. As far as I can tell, whoever factors these first gets to spend all your zerocoins ever. It's also totally and trivially quantum insecure due to Shor's algorithm.
That you admit proof verification is measured in single to double digit seconds means that both DDoS of a node is trivial and block verification time is insane; you just need to spam invalid proofs from a number of unique IPs to computationally knock a node off the network, and generating a block with more than a few transactions will be an impossibility to propagate throughout the network before another competing block is published, resulting in massive amounts of orphans and a totally insecure blockchain. You could store the verifications over time in a cache, but it's incredibly easy for an attacker to simply not publish these and then publish a block with say, 200 valid zerocoin transactions and totally screw up the network.
That you're not even storing the niZKPs on chain is another huge problem affecting network consensus based on history.