edit: Well I finished reading the entire paper, and a lot of it is above my head. Regardless, I will share the thoughts and limited insights I have obtained from the paper. Chances are if I read it several dozen more times, in addition to the cited papers included in it, that I can come to a pretty good understanding of it. I have decoded and come to understand complex technical papers such as this in the past, but only with great effort and much time. So I am reading through the Zerocoin spec after having skimmed it. I can tell you right now that a lot of the cryptography goes over my head, but I am familiar with a lot of the terms used, if not the details of the math behind them. I will post my thoughts in this message, which I am constructing as I read through the paper, in the hopes that I can shed some (likely limited) light on the details of zerocoin. The first thing I will do is clarify some of the technical terminology that I see. One thing I see is 'commitment'. An example of commitment in a cryptographic sense would be if you and I play a game of heads or tails. I flip the coin. First I take the string heads-ewijfifjw89hj83429f89342fuejgueju and hash it with sha256 to get the following hash value: 500ec7db996ec36ef30bb7b2881cd6c99f3347e3785edb3bce5cfb3a78977b6a Now I send you that value, and in doing so I have committed to heads. I ask you to select heads or tails. After you make your selection, I show you the string that I used to generate the hash value, and you hash it to confirm if I have been honest. If I cannot show you a string starting with the correct answer that SHA256 hashes to what I showed you before you selected heads or tails, then you know I am cheating. So by sending you the hash value I did, I have cryptographically committed to heads. Another terminology I see is zero knowledge proof of knowledge. These schemes are generally used for identity authentication, in a way that is more secure than passwords. With traditional password authentication, I register with a server and give the server my password, it hashes the password and stores it associated with my name. With zero knowledge proof of knowledge, I send the server a zero knowledge public key. The server can use the public key to craft challenge questions that can only be consistently correctly answered by someone with the corresponding private key, but the answers are easy to verify as true or false. The server then sends me a bunch of challenge questions crafted from the public key, I derive answers with the private key and send them to the server, and the server verifies that all of the answers are correct. It is called a zero knowledge proof of knowledge because unlike with passwords, where the server gets knowledge of my password in order for me to prove that I know the password, the server does NOT get knowledge of my private key to determine that I have my private key. A naive and insecure implementation, but one which is easy to explain, would be if I send the server my public RSA key, and to authenticate with the server it generates a random timestamped string, sends it to me, has me sign it with my RSA private key, and then verifies that the signature is valid after I send it back the signed timestamped string. Another technical term I see is cryptographic accumulator. I have read about accumulators a little bit in the past, but I never really fully wrapped my head around them. I believe that bloom filters qualify as accumulators though, and I understand how bloom filters work. Bloom filters are used to check for the presence of an object in constant time, while taking up little storage space. Essentially a blank bloom filter consists of a ton of zero bits at various positions from 0 to whatever. When you add an item to a bloom filter, you hash it and use the hash to derive a series of numbers. The derived numbers then correlate with positions in the bloom filter, and you set all of the positions to 1 to add the item. When you check for the presence of the item, you hash it and derive bit positions as before, but now you check that all of the bit positions are set to 1. This is much faster than keeping a list of hashes of seen objects and going through the entire list looking for a match. If you have a database of ten thousand item hashes, you may need to search through all ten thousand of them before determining if the item has been seen before or not. With a bloom filter, you always only need to hash the item and check the bit values at each of the positions in the filter, so the time to check for the presence of the item is constant time and doesn't grow with the number of items added (although the accuracy of the bloom filter drops with the number of items added, and increases with the bit size of the filter). Anyway, on to the paper. One thing I note is that they are indeed making a new type of coin, so to speak. However, their goal is for its value to be inherently tied to the value of Bitcoin, and for it to piggy back on top of the current Bitcoin network. Whereas in the past blind mixes have been used to achieve what they are trying to achieve, the primary challenge they claim to have addressed is creating a blind mix that doesn't have a central authority for minting blind tokens. They claim to address this by letting any user mint their own blind token, but the challenge then is to make it so users can only mint valid blind tokens if they spend an equivalent amount of Bitcoins. In this case we need a secret number R that unlocks the commitment C to obtain S. The Zerocoin          C  = fc4b5fd6816f75a7c81fc8eaa9499d6a299bd803397166e8c4cf9280b801d62c The Random Number  R  = 0283da60063abfb3a87f1aed845d17fe2d9ba8c780b478dc4ae048f5ee97a6d5 The coin serial number S  = efdf88c3315309fa0d4245389d79e035cd761813b85a954f2b924f81ee6bb248 because sha256sum(C concatenated with R) == efdf88c3315309fa0d4245389d79e035cd761813b85a954f2b924f81ee6bb248 == S We also need a zero knowledge proof  , demonstrating that she has the secret random number R, and that she knows a published C that is unlocked by R into S. I will need to keep reading to see how they achieve this, the basic sketch up on page 2 is interesting but it says the what without saying the how. Maybe they cannot even use the hashing commitment that I use in the above example, I will need to see... The complicated seeming naive solution they posted simply means going through the entire list of commitments and seeing if there is a match, because bitwise OR gets stuck on 1 which is true. 1 is true, 0 is false. (a = = b) OR (a == c) is the same as saying 0 OR 0 which evaluates to 0. (a == a) OR (a == b) OR (a == c) evaluates to 1 OR 0 OR 0 which evaluates to 1 because anything OR 1 is 1. This is a computationally expensive operation to carry out for large sets of N, because they would exhaustively search the entire list of commitments. One of the contributions they claim to have made is an accumulator that solves this problem. Although I don't know what their accumulator (A) is like, I am currently conceptualizing it as a bloom filter because that is the only sort of accumulator I know the technical details of. So rather than doing an exhaustive search for the Zerocoin C, they are creating something like a bloom filter and adding each of the values of C to it, I think that the hash value of C is a witness (what is used to determine the presence of C in the filter), however I am not totally clear on this terminology (despite seeing it in papers on cryptographic accumulators that I have skimmed yet failed to fully comprehend). Okay, bloom filters to the extent that I understand them are out. They meet the requirement of being publicly computable and verifiable, but I don't know of a way to query them with a zero knowledge proof. I assume this means that it must be possible for a user to prove knowledge of a member in the set without revealing the specific member in the set that they have knowledge of to the verifier. With a bloom filter you would need to reveal the value C, or the witness computed from it, to the verifier, in order for them to determine the presence of C in the filter. Although the current bitcoin "laundry" (mixing) services require the user to trust a and b, there are centralized blind mixing schemes that do not require the user to trust a. b is the problem that remained for blind mixing systems, and hopefully this is the issue that Zerocoin will have solved. So essentially they are using a zero knowledge proof of knowledge to determine if something exists in the accumulator. This would be like a verifier determining if an element is in a bloom filter without being given the element they are checking for. I don't understand most of the math they have demonstrated up to this point, but I can understand the "what" and the "why" or their writings so far, just not the "how". Although it is not accurate, I am going to continue conceptualizing this as a bloom filter that can be queried with a blinded witness to determine the presence of an element. A non-interactive proof simply means that there does not need to be back and forth between the verifier and the client (ie: instead of the server generating a random timestamped string and sending it to the client to sign, the client simply signs anything with their key and sends it to the server to verify the signature of. Both of these examples are horrible authentication systems, but I just use them to try to demonstrate the difference between an interactive and a non-interactive zero knowledge proof of knowledge). Sorry but I can not immediately make sense of this math. I am sure if I spent some time on it I could wrap my head around it much better, but I am not skilled enough to read this and immediately decode what is going on. I can see they are using RSA though . So the summary is that they have created a decentralized blind mix using zero knowledge proof of knowledge combined with a special cryptographic accumulator. Whew hopefully away from the "Makes my head hurt" section of the paper now. As you can see from the above paragraph, Zerocoin is a separate currency system, but the value of a Zerocoin is inherently tied to the value of a Bitcoin, and it piggy backs on the network. In order to get a Zerocoin, Alice must spend a Bitcoin, apparently the Bitcoin does not go to anybodies actual wallet but rather is associated with the Zerocoin C that Alice has minted. So in summary I do not fully understand the "how" of what is happening here, but I do have a pretty decent grasp on the "why" and the "what". Zerocoin is a decentralized blind mixing scheme that they propose be integrated with Bitcoin, although it can also run separately of it. It is the first decentralized blind mix in the literature, and is bleeding edge if it lives up to its claims (I certainly am not capable of verifying its security). It is based off of a special sort of cryptographic accumulator that is compatible with blinded witnesses, zero knowledge proofs of knowledge for computing blinded witnesses and cryptographic commitment schemes. It is a separate currency from Bitcoin, but they propose that it be merged into the Bitcoin network in such a way that the value of a Zerocoin is inherently linked to the value of Bitcoin it can be redeemed for. They want to piggy back on top of the established Bitcoin network for many of the components required for their system. In essence, their goal is to cryptographically obfuscate the transaction history of Bitcoin, which is currently public knowledge. They claim to have addressed several issues, primarily they remove the need to trust a traditional laundering service from linking input and output coins, and more importantly they give the security assurances of blind mixing while removing the ability of a centralized authority (the blind mix) to steal the bitcoins sent through them. I can say that I am actually very excited about Zerocoin and that I think it will be a massive improvement for Bitcoin. People who can read that paper once and understand it fully will need to verify that the math and logic are sound though.