32

A recent approach to creating a decentralized online currency, called Bitcoin, has been generating some interest. The goal is to have a way to transfer currency without a central authority and without double spending or counterfeiting. Their approach is to have all the nodes in the network try to verify a transaction by doing a proof-of-work computation and then the transactions with the most verification are considered official. If an attacker wants to forge the official record (to reverse their first spending and use the coin again), then they must have the majority of the computing power in the network. The biggest downside is that in this scheme, the record of all transactions must be public, which the author of the Bitcoin paper assumes is a must:

The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced.

Is it obvious that all transactions must be publicly known in any such scheme?

It is known that schemes without a public-transcript can be implemented when you have a central authority/mint, but I am only interested if it is possible for a decentralized approach.

Notes

I originally asked this question on cstheory. Also, I am not familiar with the tagging on crypto.SE, so any help is appreciated!

Community
  • 1
Artem Kaznatcheev
  • 421
  • 4
  • 6
  • Once the Bitcoin Stackexchange site is in public beta, should this question be migrated there? http://bitcoin.stackexchange.com/ – ripper234 Aug 31 '11 at 00:22
  • 2
    @ripper234 no, it shouldn't. This is already the second place I asked the question (it was asked at cstheory originally) and it was decided in a meta discussion there that I should repost. Usually questions are only migrated if they are off-topic on the original site; this question seems to be ontopic here, and already generated a very good answer. – Artem Kaznatcheev Aug 31 '11 at 00:30
  • 1
    Agreed, digital currency theory should remain inside crypto.SE. – Jeff Burdges Dec 03 '11 at 21:14

2 Answers2

23

For such a scheme to work, if I have some currency, I have to be able to give it to Abel and I have to be able to give it to Beth, but I have to be unable to give it to both Abel and Beth. This means that giving the currency to Abel has to somehow make me unable to give the currency to Beth even though I previously could do that.

There are three mechanisms by which this can be accomplished:

  1. There can be a central authority. To give the coins to Abel, I must tell the central authority that I have done so. The central authority would then prohibit me from giving the coins to Beth. This means giving coins requires both approval from the central authority and reporting to the central authority.

  2. There can be a distributed secure device. To give the coins to Abel, I must tell the instance of the secure device that holds the coins. The device will then prohibit me from giving the coins to Beth once it has given them to Abel. This means coins must be held in a physically-secure device. In practice, it also requires a central authority to load the devices and issue keys to them. (I need to prove a secure device was involved in the transaction, which requires the device to have a certificate, which requires some authority to issue such certificates.)

  3. At least some aspect of all transactions can be public. Thus, if I give the coins to Abel, there will be a record Beth can easily find. Beth will know the coins are not mine to give.

Bitcoin chooses the third approach. This seems the best approach for cryptographic decentralized currencies. There is no fourth approach known.

Now, the only information about the transaction that needs to be public is enough information to prove I have the coins and prove that I didn't transfer them elsewhere. As it happens, the Bitcoin protocol leaks much more information than this (for example, the account I transferred the coins to). The protocol could have been designed to make less information public if that was desired.

The coins need be traceable back to their origin. But whether or not you can track the particular accounts they passed through is an implementation decision.

For example, a hypothetical coin could use the following mechanism: Alice wants to send some coins to Bob. She knows Bob's public key. She generates a random private key just for this transaction and encrypts it with Bob's public key. She then publishes a transaction transferring coins to the public corresponding to the random private key she generated along with the encrypted version of that same key that she encrypted with Bob's public key.

Now, Bob will see a transaction that his private key is able to claim. Nobody else will know the transaction was to Bob because neither Bob's public key nor any analog of it appear in the block chain. Bob will have no idea the coins came from Alice and nobody else will have any idea the coins went to Bob.

This method still leaves the coins fully traceable. But no traceable accounts ever appear in the block chain.

This solves two 'problems' with Bitcoin. If I publish a bitcoin address somewhere, anyone can see how many Bitcoins that account got. If someone wants to transfer me bitcoins that cannot be traced, he must obtain a one-time use account from me, which he cannot easily do if he wishes to give me the coins anonymously.

You can still generate and use one-time accounts with Bitcoin, but you cannot broadcast them or they cease to be one-time accounts. And there is no easy way for someone to anonymously request one from you.

You might think this means every account must be tested to claim every transaction, resulting in an inefficient scheme and making things like web-based mass wallets computationally impractical. However, I've discovered a truly marvelous solution to this problem, but this answer is already too long.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
David Schwartz
  • 4,729
  • 19
  • 31
  • can you give an explanation of an implementation that does not keep track of the accounts the coins passed through? Since that would answer my question very nicely. – Artem Kaznatcheev Aug 25 '11 at 17:07
  • Sure. To transfer coins to Beth, you perform the following operations: 1) Generate a random secret key. 2) Encrypt the secret key with Beth's public key. 3) Publish the transfer of the coins to the public key corresponding to the secret key you generated and the encrypted private key. 4) To claim the coins, Beth decrypts the secret key using her secret key and can then spend the coins. 5) Beth's public key or account information is never disclosed. Effectively, you generate a one-time account just to receive these coins and tell Beth how to claim them in a way only Beth can understand. – David Schwartz Aug 25 '11 at 17:16
  • 1
    @David: as I understand Bitcoin, anybody can have as many accounts as one wants, and it is even recommended to use a new account number (= key pair) for each transaction one is receiving. Isn't this equivalent to your proposed scheme (other that Beth now needs to keep track of more private keys)? (Also, your usage of private and secret seems a bit mixed up.) – Paŭlo Ebermann Aug 26 '11 at 11:09
  • 2
    No, it's not equivalent. Say I want to run an advertisement in a magazine and give people an address they can use to send me bitcoins. How can I do that and hide how many bitcoins the advertisement yielded? And Beth needn't keep track of any additional private keys -- the encrypted private key is published in the block chain. She can decrypt it with her single private key whenever she needs it. – David Schwartz Aug 26 '11 at 11:34
  • Or imagine if I put a bitcoin account address in my profile for 'donations'. Say you want to send me a large number of bitcoins anonymously. You don't want everyone to know I have this huge sum of money -- maybe they'll come after me to steal it. So what can you do? You can ask me for a private address just for you, but then you can't give me the money anonymously. Had bitcoin chosen the scheme I explained above, this would trivially be solved. I'd just suddenly find a transaction in the block chain that my private key unlocked. – David Schwartz Aug 26 '11 at 11:36
  • @David Schwartz: you are absolutely correct that my 4 was your 2. My only excuse: it was late. I removed my comment. – fgrieu Aug 26 '11 at 11:51
  • The "keeping track of private keys" was aimed at bitcoin, not your example. You are right, public addresses with hidden transactions are not possible with bitcoin, but would be in your case. (Could you add this possible scheme to your answer, instead of letting it hidden in the comments?) – Paŭlo Ebermann Aug 26 '11 at 14:02
  • @David this is a good answer; but it feels like two in one. In particular you give some arguments for what can't be achieved, and then you give a second answer which shows an improvement on bitcoin's scheme. I would like to accept the second answer, but I don't find the first one rigorous enough. If you could make the second part of your answer and maybe even elaborate on "I've discovered a truly marvelous solution to this problem, but this answer is already too long." as a separate answer, that would be awesome! – Artem Kaznatcheev Aug 30 '11 at 21:43
  • Can't this be achieved with Bitcoin as it is, by Alice sending Bob the generated private key (still encrypted with Bob's private key) through a side channel rather than embedded in the block chain? – JGWeissman Oct 04 '11 at 19:41
  • @JGWeissman: If you have a side channel, it's better for Bob to just generate a new address and have Alice send to that. That way, only Bob knows the key. – David Schwartz Oct 04 '11 at 20:33
  • @David, I think this can be accomplished with the various "send coins to script with this hash" proposals (some of which are called "OP_EVAL"). But you're right that the original bitcoin does not have a mechanism for broadcastable one-time-use addresses. – Barbering without a License Jan 03 '12 at 18:57
  • @David Schwartz: your "encrypted key within transaction" protocol is intriguing, and might one day make it into a future better Bitcoin. But doesn't it have the disadvantage that if Alice is sending to Bob, Alice is not truly relinquishing control over the sent coins, until Bob grabs them and moves them to a different key? (After all, Alice still knows the private key she sent in only-Bob-can-decrypt form to Bob!) You might say "So what? Bob just grabs them every so often." But one can imagine scenarios where there are economic or political costs / risks for Bob being "always on" in that way. –  Mar 26 '12 at 21:54
  • @IainStewart: Welcome to Crypto Stack Exchange. Normally, to be able to add comments you have to have a minimum of 50 reputation (to be gained by upvotes on questions or answers, and approved edits). I converted your answer into a comment, using my moderator powers. – Paŭlo Ebermann Mar 26 '12 at 22:07
  • @IainStewart: Yes. But this also has the benefit that Alice can know Bob got his coins and if the account is lost, Alice can get them back. Bob need not be always on, he need only be on when he wishes to lock coins into his account. I consider this, on balance, a plus. But I could see how people might disagree. – David Schwartz Mar 26 '12 at 22:09
  • 1
    "However, I've discovered a truly marvelous solution to this problem, but this answer is already too long.", I'm sure you did Mr. Fermat ;) – capn Apr 19 '12 at 17:58
  • @IainStewart: There's actually a trivial solution to that. Instead of the transaction including the encrypted private key needed to claim the funds, it can include the encrypted "private key offset" that the recipient can apply to his private key to produce the private key he uses to claim the funds. Since the sender doesn't know the recipient's private key, he cannot claim the transaction. So you can get it that way if you want it. (This works the same way deterministic wallets work where you can craft a new public key that only someone else knows the corresponding private key to.) – David Schwartz Oct 18 '12 at 07:10
2

Zerocash is such a decentralized currency scheme. A Zerocash transaction completely hides the origin, amount, and destination of the transaction.

It achieves this via a cryptographic tool called a zkSNARK, which effectively allows you to prove the validity of a statement in "zero knowledge", i.e. you leak nothing more than the truth of the statement.

In Bitcoin, you prove that you own a coin by using your private key to sign a transaction on that coin. As an analogy, consider the coin to be a locked box that you unlock to prove that you own it. In Zerocash, however, you use a zkSNARK to prove that you can unlock the box. Since this is done in zero knowledge, no information except for the truth of this statement is leaked.

It's more complicated than this, and I'm leaving out many details, but its a decent approximation of what's happening.

Community
  • 1
Pratyush Mishra
  • 96
  • 4
  • 1
    Mentioning Zerocash is interesting, but unfortunately your answer doesn't explain the crucial part: why is it that before spending a coin, I can prove that I own it, but after spending it that proof no longer works? – Gilles 'SO- stop being evil' Dec 27 '15 at 10:17
  • It appears that zerocash ensures that you can't double-spend by indeed making the information about which coins were transferred public; during a transfer, old coins are destroyed and new ones created with equal value. So while it hides the details of the transaction, it does still require that the fact that a transaction occurred be made public. – Logan R. Kearsley Feb 08 '19 at 20:57