6 ms·

Show HN: Logcoin – Toy crypto-currency based on a zero-knowledge protocol

synapticrelease 11y ago
Hi, 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!
- drdeca 11y ago
  This looks cool! 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?
  - synapticrelease 11y ago
    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.
im3w1l 11y ago
Sorry for being harsh on a newcomer, but this did not live up to my expectations based on the title. It seems to be strictly worse than bitcoin, let alone zerocoin. It needs a central tracker, and it needs a secure offline channel to transmit keys. The reason zerocoin uses zero-knowledge proofs is to make it impossible to trace the history of a coin. This is another property that this project does not have.
- lambda 11y ago
  This comment does seem fairly harsh for something advertised as "a toy." Why would you expect a toy to be state of the art? When I see that phrase, I think of something that is a personal learning experience, might have an interesting idea or two but is not expected to replace anything that already exists.
  - synapticrelease 11y ago
    "Why would you expect a toy to be state of the art?" http://www.8-bitcentral.com/images/nintendo/promo/virtualBoy/virtualBoy_1b.jpg http://www.8-bitcentral.com/images/nintendo/promo/virtualBoy... Real 3d graphics, that's why!
  - im3w1l 11y ago
    I expect a toy example to be theoretically sound, but using shortcuts to get a practical realization. For all the fancy cryptography this uses, I don't see how it provides any more security properties than a central actor having a databases of balances and requiring a cryptographic signature (like RSA, ECDSA etc) to authorize transactions. I don't see an extension path either. Since the zero-knowledge proof is interactive, I am unsure how the central tracker could even be audited not to spoof transactions.
    - synapticrelease 11y ago
      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.
amluto 11y ago
Some thoughts: Why did you pick a modp group instead of an EC group? Why doesn't Bob send y? Y is derivable from what Bob sends. (Your zero knowledge claim is at least a bit wrong, since Bob is sending correlated numbers and, in fact, y can be derived from them.) Bob's sent values can be rewritten as y2^b, y2^c, and y^-1 * f_1 * f_2, which makes me wonder why f_3 is sent. Why does Bob prove knowledge of x+b+c? Can you clarify the spoofing attack? What prevents double spending if the tracker is malicious?
- synapticrelease 11y ago
  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).
  - synapticrelease 11y ago
    I should also mention that the protocol to verify x is separate and is a valid ZKP.

Hi, 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!

drdeca 11y ago
This looks cool! 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?
- synapticrelease 11y ago
  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.

im3w1l 11y ago

Sorry for being harsh on a newcomer, but this did not live up to my expectations based on the title. It seems to be strictly worse than bitcoin, let alone zerocoin. It needs a central tracker, and it needs a secure offline channel to transmit keys. The reason zerocoin uses zero-knowledge proofs is to make it impossible to trace the history of a coin. This is another property that this project does not have.

lambda 11y ago
This comment does seem fairly harsh for something advertised as "a toy." Why would you expect a toy to be state of the art? When I see that phrase, I think of something that is a personal learning experience, might have an interesting idea or two but is not expected to replace anything that already exists.
- synapticrelease 11y ago
  "Why would you expect a toy to be state of the art?" http://www.8-bitcentral.com/images/nintendo/promo/virtualBoy/virtualBoy_1b.jpg http://www.8-bitcentral.com/images/nintendo/promo/virtualBoy... Real 3d graphics, that's why!
- im3w1l 11y ago
  I expect a toy example to be theoretically sound, but using shortcuts to get a practical realization. For all the fancy cryptography this uses, I don't see how it provides any more security properties than a central actor having a databases of balances and requiring a cryptographic signature (like RSA, ECDSA etc) to authorize transactions. I don't see an extension path either. Since the zero-knowledge proof is interactive, I am unsure how the central tracker could even be audited not to spoof transactions.
  - synapticrelease 11y ago
    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.

amluto 11y ago

Some thoughts: Why did you pick a modp group instead of an EC group? Why doesn't Bob send y? Y is derivable from what Bob sends. (Your zero knowledge claim is at least a bit wrong, since Bob is sending correlated numbers and, in fact, y can be derived from them.) Bob's sent values can be rewritten as y2^b, y2^c, and y^-1 * f_1 * f_2, which makes me wonder why f_3 is sent. Why does Bob prove knowledge of x+b+c? Can you clarify the spoofing attack? What prevents double spending if the tracker is malicious?

synapticrelease 11y ago
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).
- synapticrelease 11y ago
  I should also mention that the protocol to verify x is separate and is a valid ZKP.