Topic: Zerovert - First Truly & Only Anonymous Coin with Zerocoin | Mandatory Upgrade ! - page 21. (Read 50921 times)
November 05, 2014, 02:24:11 PM
too much premine
November 05, 2014, 02:18:49 PM
November 05, 2014, 02:02:27 PM
Hm, do you have good reading links so I can understand this? No work until monday, so there's some time 
There's a basic description of how an RSA accumulator works here:https://eprint.iacr.org/2009/625.pdf
See 2.2, and ignore the initial stuff relating to the hash tables.
Quote
With their plan of becoming a sidechain to vertcoin, could it be possible to retain some form of security post 5-15 years, assuming the transfer is possible?
Um, if the method used to spend the old coins is totally insecure, probably not unless they're additionally wrapped in some way eg a normal ECDSA signature that is otherwise unused.Quote
With the increased verification time, would ddosing something like a centralized pool become trivial, or is that something separate?
DDoSing a centralized pool is already trivial. But DDoSing all the nodes on the network is much harder, and the longer verification time makes that trivial.Quote
What historical information can be garnished from storing the niZKPs on the chain?
That a transaction in the past was actually valid or not. 
November 05, 2014, 01:59:12 PM
November 05, 2014, 01:58:23 PM
hey if i want to rent a rig for this, what do i use? ports and that for MRR info
Scrypt-N (or N-Scrpt) and everything else is found - as usual - at the Getting Started page:
./cgminer --scrypt-n -o stratum+tcp://hashmonster.net:1334 -u Weblogin.WorkerName -p WorkerPassword
November 05, 2014, 01:56:36 PM
hey if i want to rent a rig for this, what do i use? ports and that where to point miner?>
November 05, 2014, 01:45:39 PM
Nice README.md you have there in the Github. 
November 05, 2014, 01:43:40 PM
how many zerocoin in circulation ? thanks
November 05, 2014, 01:41:16 PM
Is this true ... rpcport=31397 ....
It's what I picked. You may pick whatever you like for the port.
The developer will likely settle on a unique port at some point, but for solo mining it's just a local port, so as long as you're not running anything else on that port you're fine.
Also, there's a pool up now
November 05, 2014, 01:39:45 PM
November 05, 2014, 01:38:11 PM
Code:
rpcuser=username
rpcpassword=password
rpcallowip=127.0.0.1
rpcport=31397
daemon=1
server=1
Is this true ... rpcport=31397 ....
November 05, 2014, 01:31:38 PM
Seems interesting watching for further info.
November 05, 2014, 01:27:14 PM
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
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.
Hm, do you have good reading links so I can understand this? No work until monday, so there's some time
With their plan of becoming a sidechain to vertcoin, could it be possible to retain some form of security post 5-15 years, assuming the transfer is possible?
With the increased verification time, would ddosing something like a centralized pool become trivial, or is that something separate?
What historical information can be garnished from storing the niZKPs on the chain?
November 05, 2014, 01:20:04 PM
http://zerovert.org/mining.html - Thanks
November 05, 2014, 01:19:08 PM
Hey guys, thanks for your requests adding a pool for this, since there is no source available and so many scams/trojans/malicious stuff I cannot provide a pool yet as my regular checks cannot be run over the wallet.
I'll provide a pool on a dedicated machine later one, it will have no connection to the suprnova network so it cannot be of any harm.
I'll provide a pool on a dedicated machine later one, it will have no connection to the suprnova network so it cannot be of any harm.
November 05, 2014, 01:17:48 PM
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
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.
November 05, 2014, 01:15:03 PM
With this being closed source... it could be full of backdoors. Even with the source code, even assuming it has zerocoin stuff in it, it would take time to analyse it properly and determine there are no obvious backdoors for the devs. With just binaries it's mission impossible, there's no way to tell if this is a scam.
C-cex must be desperate..
November 05, 2014, 01:13:52 PM
yes, ok..
No, actually blocks are going quite slow. Thanks ccex for adding the coin and taking a chance on this one.
November 05, 2014, 01:12:06 PM
yes, ok..
November 05, 2014, 01:07:05 PM
@Boristhespider === would not let start without POOLS 
Jump to: