Topic: New privacy centric altcoin - ideas (Read 593 times)

You are perfectly right.  A problem with ZCASH is that you can do also "normal transactions" like bitcoin transactions.  In fact, for a long time, I wasn't sure about it.  But ZCASH is essentially the realization of the old proposal of implementing zerocoin into the bitcoin protocol.  Because bitcoin doesn't move, the ZCASH team essentially decided to launch a new "bitcoin" with, this time, the zerocoin protocol (the improved version, zerocash) incorporated.  So you can have zcash "coins" which are like bitcoin, and which are transparent ; and then you can transform coins into notes, which are the anonymous version.  You can also redeem coins with notes.  The notes are anonymous because when you transact notes, you do this with a zero knowledge proof: you prove that you have been using a valid note in your transaction, but people don't know which one.   So the anonymity set is all the notes that have ever been created.  The ZK proof also indicates that this note was not yet "spend".  The next time you try to spend the same note, it won't work, you will not be able to make a new ZK proof of valid note.   But nobody apart you knows which note.

These notes ZK proofs are very computationally heavy to make (about a minute on a high end PC).

So essentially you have:

normal "bitcoin" transaction: (coins) -> (coins)

ZK proof: (coins + ev. notes) -> (notes)    OR (notes) -> (coins + ev. notes) OR (notes) -> (notes)

Could you expand a bit on this? I haven't read much discussion of it. I would think that the possibility of some recipients being exposed (by not using anonymous transactions) entails significant privacy concerns for those who are using them.

I think the trusted setup can be made more trustworthy, if there is an open participation, and if there are MANY participants.  I already suggested this.  Instead of 18 participants or so, you could provide for thousands of participants, essentially everybody who is interested.

A suggestion is this: consider, say, 20 000 participants in the setup (with the idea that less people will actually show up).  Ask people on bitcointalk to post their public parameters.  Up to 20 000 people can do so before a given date.  We can all see those contributions, and YOU can see YOURS. 
At the given date, include all the published public parameters in the final trusted setup parameters, and generate as many others to reach 20 000 in total.  The only thing YOU have to verify is that YOUR parameters are part of it.  Then you know if you can trust yourself.
It doesn't matter if 99% of the others are "Sybil" parameters: your parameter is sufficient to give you some trust in it.
You can also verify that all the published parameters are included.   It would be a good idea if people could sign their parameters with PGP signatures, so that we have an idea of the diversity of the number of people involved.

But again, if YOU are part of the trusted setup, YOU can trust it.  With, say, 20 000 participants, chances are that many people can trust the trusted setup, and in the end, even people that are not part of it (later) know maybe some people that are part of it, and which they can trust.

Of course, you can never take away the existential doubt of a trusted setup, unless you are part of it and you know it ; but if, say, 20 000 people are in that case, then I think the trusted setup can in practice be trusted.


You definitely should eliminate it.

You should also make anonymous transactions compulsory: ONLY notes after the coinbase creation. 

As someone said somewhere: if you use ZCASH, it is for its anonymity.  But then you should use anonymous transactions.  Even if they are "heavy".

The main drawback of the trusted setup is that it is not auditable. It makes it impossible to ever know if the setup was corrupted, and if the supply really is limited to 21M.

A few friends and I are considering forking Zcash with a couple small tweaks. 1) address the trusted setup, perhaps by enforcing a periodic coin audit (transaction which reveals not who, but how much owned) at the protocol level. 2) reduce or eliminate the founder's reward. (I'm for eliminating it, but I understand that it's tough to motivate anyone to work entirely for free)

Zooko and the Zcash team have made pretty clear -- they aren't addressing the trusted setup. So I think this may be a good opportunity to address what I see as an insane existential risk to the protocol, while drastically cutting down on [at least] the founder's reward.

PS: interested devs, PM me.

Again, I think you are confusing operational security with the coin protocol.  There are of course coin protocols that are easier to make secure in operation than others, but the way you encrypt your wallet, hide the data, or the human interface to enter one's pin code, the way the networking is done and so on, is NOT part of the coin protocol.  For instance, hiding your IP can be done in bitcoin by transmitting the transactions over TOR or the like.  You could send transactions by paper mail if you want.  These operational security and anonymity questions have nothing to do with the coin protocol itself.
For instance, you might use TOR and many other means to hide your identity, when you put your bitcoins on an exchange, the transparency of the block chain kills most of that effort.  On the other hand, you might use monero to obfuscate the transaction history, but if you do this on a compromised machine or a compromised network, it is of no use.

But the coin, and the opsec, cover different aspects of the security and anonymity question.  There's no point in trying to solve opsec questions with the coin protocol, and there's no point in trying to solve coin protocol questions with operational security tools.  Although one has to keep in mind one when dealing with the other, they are nevertheless different things.

The relationship is somewhat similar between cryptography and OPSEC.  Both address different problem domains, although one has to take into account the requirements of the other.

There's no point in using AES-256 if you have a key logger on your machine.  But you shouldn't use broken crypto for your password encryption either.

(1) The foundation is to run the network through Tor, I2P or Freenet.
- Freenet may offer an opportunity for a decentralised blockchain.

(2) A version of confidential transactions and a way to automatically mix all change addresses and keep a "repository" of common denominations for merging inputs.
- Need solve de-anonymization by (a) address reuse (b) change address analysis (c) merged input analysis
- No correlation between any change address or any other address on the network

(3) A 'zero-footprint' wallet w/ a strong PIN access system.
- If an attacker either infects your computer or have physical access and wants to run a version of, say BTCscan (https://gist.github.com/chriswcohen/7e28c95ba7354a986c34) to look for base58 strings or something of that sort.
- If an attacker gains access to your computer, they should not find any trace of the coin. The software runs "within" itself and does not leave any artifacts etc.

So, a pragmatic approach to anonymity taking into account the methods that may be used to de-anonymize a user.

Any thoughts?

Here's something I was thinking about some time back. i don't know if it is within the scope of your question, though:

I think if you want an anonymous coin, you need an anonymous net as well, i.e. Tor, I2P, that kind of stuff. Not necessarily only to send the coins over it, also because this is just part of privacy. These things rely on relay nodes. I think it might be a good, or at least interesting idea to encourage running such a node by rewarding the node operator with coins. E.g. If your coin is PoS anyway, you could increase the reward for people who run such nodes.
My brain is about to shut down, so i apologize for the short and vague post.

You should separate the OPSEC from the coin protocol, although you should keep it in your mind when designing the protocol.
ZCASH has good ideas, but the way it is put into music is wrong.  What is good in zcash, is that the anonymity set is total.  That's better than in monero, where it is initially only a few, growing over time.  (monero is really not bad, btw).
The problems with ZCASH are:
- the company post premine
- the way the trusted setup is handled
- the fact that transactions are not anonymous by default.

I would suggest to do away with the premine, by not having any genesis block, but by forking off from bitcoin.
I have already done some suggestions for the trusted setup: that's possible if there are potentially many thousands of participants in its setup.
Making anonymous transactions ONLY is a necessity.

I am planning to create a new privacy centric coin and try and plug any holes that exist in SDC, XMR or Stealth etc. and approach the matter in a more pragmatic way. What are the main issues you see in the current "anonymous" coins and what privacy features have not yet been implemented?

As far as I can tell, a motivated attacker / investigator can use a whole range of advanced techniques and statistical analysis to de-anonymize a network.

Any ideas?

ED:

(1) The foundation is to run the network through Tor, I2P or Freenet.
- Freenet may offer an opportunity for a decentralised blockchain.

(2) A version of confidential transactions and a way to automatically mix all change addresses and keep a "repository" of common denominations for merging inputs.
- Need solve de-anonymization by (a) address reuse (b) change address analysis (c) merged input analysis
- No correlation between any change address or any other address on the network

(3) A 'zero-footprint' wallet w/ a strong PIN access system.
- If an attacker either infects your computer or have physical access and wants to run a version of, say BTCscan (https://gist.github.com/chriswcohen/7e28c95ba7354a986c34) to look for base58 strings or something of that sort.
- If an attacker gains access to your computer, they should not find any trace of the coin. The software runs "within" itself and does not leave any artifacts etc.

So, a pragmatic approach to anonymity taking into account the methods that may be used to de-anonymize a user.

Any thoughts?