This sounds like it could very easily be abused as a way to peddle supplements while skimping on the experimentation aspect. It's a good idea though. Do you have plans to include something other than supplements? For instance, common foods (to be consumed daily for long periods of time) or simple activities/exercises? You could still derive revenue by selling the equipment/ingredients through your platform but it would allow you to vary the product while maintaining the consumer base. Also, doing it with something other than supplements could be cheaper and more newsworthy if you do discover something. Very interesting!
Thank you for your informative and critical feedback - skepticism is at the heart of science! Very true, the system could potentially be used to promote a specific agenda. However, we very much want to avoid a system that allows something such as this as much as possible. Ideally through implementing open-source / 3rd party / community-input based protocols. If you have suggestions in this regard we'd love to hear them!
And yes, we plan on including food at a later date!
Read the readme again. The interactive ZKP does not reveal classified information about the actual transaction to the tracker, which is required to authorize it.
In theory, yes, a tracker could be malicious. It could even simply delete its record of all the coins and then refuse all transactions. Or change every coin so it cannot be spent. Actually the one thing it couldn't do is spoof transactions, because it doesn't know the secret key of a single coin it tracks. So it would have to make up a new coin, which would be easily detectable by other trackers because there must be a public consensus on how new coins are created (i.e., their public keys must be prime). So you would, once again, have to compromise every single tracker to spoof a transaction. Then you are right that there is no way to audit, but then you have bigger problems anyway (like people stealing money from exchanges) even before you get there.
Which brings me to the /real/ problem with my implementation, the coins are not worth nearly as much as bitcoin or zerocoin yet :P.
Alice has a secret key. She wants to prove this to Tom the tracker. He issues her a number of challenges until he is convinced she has the key.
Suspicious Simon now wonders if Alice actually had they key. Maybe she didn't and Tom gave her easy challenges? How can Simon be sure Alice has the key?
So, what I mean by zero knowledge is that there is zero knowledge of the secret key x, the discrete log of y. Y itself is supposed to be derived, that's part of the protocol. But when Bob randomly offsets the x-value before sending it, he is committing to a value of x, c, and b which he must then verify. It will be impossible for him to verify the c and b if he doesn't know x, which is important (see below).
modp groups are easier to implement, I was look into EC but I may come back to it later.
Bob doesn't want to send y directly because then another man in the middle could, before the transaction times out, forward y, spoof his own b and c, forward the verification of x and then verify his own b and c. Then he cannot spend the coin but he can make it unspendable.
If one tracker is malicious, he'll be out of sync with all the other trackers to which the transaction is also broadcast to. Every single known tracker would need to be compromised (they are all public).
No reason to be sorry. well, the title was supposed to be longer :P. I was going to write the same as the github title but it didn't fit. It is clearly a toy---ahermmg---semi-serious theoretical exercise, and not a real competitor to bitcoin or zerocoin, you are right in that respect.
This (as far as I know) does make it impossible to trace the history of a coin, because there is no recorded transaction history, assuming you don't send the transaction details directly from your ip (and valid coin transfers are mathematically impossible to spoof from e.g. an exit node). You also don't need a centralized tracker, you just need a public record of all known coins which is kept in sync across several mirrors. I should clarify that in the readme; the only reason why I mention assuming a centralized tracker is for the performance estimate, because syncing trackers would induce overhead. Unless you see something I am missing...
The reason why this uses zero-knowledge proofs is twofold; first, to allow anonymization of individual transaction ids by ensuring it is impossible to spoof transactions without knowing the secret key of the corresponding coin, and second to avoid the use of a blockchain which further degrades anonymity. Again, it may be that you have discovered a reason why this does not hold, in which case I would be interested to hear it!
Regarding the matter of coin transfer, this was a design decision because of the project scope. I could have spent many days implementing a transaction system which did not depend on the secrecy of keys, but I have other commitments. That being said, there are a subset of transactions (involving money, but also authentication of physical goods in transit, for example) which can potentially be treated this way. For instance, I can use it to verify the user is in possession of a particular hardware (a physical "coin") which stores the secret key in encrypted form. Which could be useful in e.g. shipping applications, who knows.
You say that the trusted actor updates the public key of a coin. This means that it is known which former key corresponds to which following key. Thus the central actor can trace the history. If you have many trackers, then everyone can trace the history.
Yes, but it only knows the public key. Which is not a number in any way associated publicly with the identity of the owner...it's essentially a (discrete exponent of a) random number that identifies the coin.
I have no idea if I'm doing this right because I am new to HN. But here is a very early WIP of a zero-knowledge cryptocurrency. I try to keep code terse to avoid bugs. Have at it!
However, if the tracker is centralized, doesn't protection against double spends basically come for free?
Or, maybe not because of the other things?
Oh, wait, ok so in this situation does the tracker have any privileged information?
It doesn't look like it, So, another party could take the place of the tracker if the tracker went down?
I don't understand the proof of stake bit in the readme. I don't see anything about staking the coin, and I generally don't understand how proof of stake applies to something like this?
the tracker is public and mirrored, and the idea is to reinforce your claim of ownership you send it to as many known trackers as you can within reason.
The proof of stake is essentially for free; as described above, by verifying you know the current secret key of the coin, you verify you own that coin. There is no transaction history; the coin is secret and updated randomly on every transaction.
