Bitcoin Forum

Let's discuss this paper: http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf

What are your thoughts on this? I don't understand a lot of the technical stuff in the paper, so I'm interested in hearing your opinions.


https://i.imgur.com/NmxgXd8.png

i gave the paper a read and it is indeed interesting.

the complexity of the scheme is high and has large tx sizes. feels a bit overkill

it is targeting much smaller audience, the size is in this case not an issue.
the data of zerocoin public dashboard do not have to be preserved the same way as blockchain.

The most important reason why this will never be used over Bitcoin is that it requires a TRUSTED THIRD PARTY to create the initial parameters. This TTP could, in theory, trace any coin in circulation. So how the Bitcoin community will choose this TTP ?

Why not let the FDIC be this TTP? Oh, yes... this is not the Bitcoin philosophy :)

PS: I designed a protocol that does not have this problem (but have another less important weakness) , but well, never published, so Matthew Green deserved much credit. I hope I can publish it soon...

I will post more about Matt protocol shortly, when finish checking it...

Sergio.

The zerocoin paper doesn't indicate a trusted third party actually it indicates the exact opposite.

This is the first thing written about Bitcoin that's been worth reading in quite a while.

ByteCoin

Neat, so this is the replacement for mixers.

PAGE 3, first column:

" With no trusted parties, the accumulator and its associated witnesses must be publicly computable and
verifiable (though we are willing to relax this requirement to include a single, trusted setup phase in which parameters
are generated). "

PAGE 4, second column:

"We note that the Setup routine may be executed by a trusted party"

The point is that by choosing RSA as the crypto function, they require a TTP.

Maybe it could be adapted to other crypto function, but it will change all the procedures, since they use the internal mathematical properties of RSA.

My point is that it doesn't require a trusted third party.  Yes they seem horrible naive (academics usually are).  A privacy "coin" where the govt has the backdoor key has essentially no utility.  Bitcoin's pseudo-anonymous capabilities are more that sufficient for "casual anonymity" (not wanting your wife to know where you spend your money).  Anyone interested in something stronger isn't going to be ok with backdoors.

Sorry about the Off-topic: If someone out there wants to write/implement my proposal for an anonymity layer for Bitcoin, and has in depth knowledge of crypto and math, then I'd gladly co-author the paper on APPECoin...

http://jheusser.github.io/2013/02/03/satcoin.html is also an interesting read, even though it might not help much with actual Bitcoin development.

I also lover this paper here though, great that people start thinking of new ways to make Bitcoin useful for some special purposes!

Important work. Also if bitcoin does not adopt a robust privacy strategy it risks another alt-coin will gain a competitive first mover advantage for what I consider to be an extremely desirable (marketable) property for monetary instruments.

Seems complicated, but also looks like serious work.  I will need some time to understand it.

It seems to me they overestimate the need for full anonymity, though.

This already exists, it's reinventing the wheel.

Not sure how cryptocurrency is any less legitimate than actual cash, the only real difference is that it's not centralized and inflatable like a government made currency.

My initial read of their paper was interesting, but it was two to three orders of magnitude more resource intensive than would be required to make it actually viable.  ... This is still impressive since 1000x too big/slow is still way better than infinite, which was the best alternative I had for something that was actually decentralized.

(The lay explanation of Bitcoin was _meh_ as it glosses over the blockchain which is the only really novel and somewhat non-obvious part of the system at large)

My greatest concerns were: 50Kbyte transactions with 0.5 second validation time, stored in a step-2-then-a-miracle-occurs (DHT, presumably an attack resistant one created by unicorns), with a cryptographic accumulator which grows without bound and can't be pruned like the block-chain or compactly zero trust queried like the UTXO can if we add a commuted UTXO tree.

Something like this could be used in an external system and tied in via N of M multisig, and the authors acknowledge that but if you're going to take accept a (distributed) point of trust for that, you can use a chaum token like service can be constructed less computationally and bandwidth intensive than this.

On the plus side— approaches can only get better.

I reviewed this paper back in early March. Matthew Greens blog post more or less echos the feedback I gave them back then (in particular, their understanding of the performance requirements of verification were badly incorrect). I also mentioned difficulty of implementing in SPV clients and the overall complexity of the scheme.

Overall, I think the plan we've been working towards for privacy will work better, or at least is more deployable. But it's great to see this kind of research - as Gregory says, these algorithms only ever get better.

Nice to hear some opinions on this. Doesn't look very promising based on looking at your feedback.

I agree that true anonymity is nice to have, but it must be able to accommodate the space limitations of the block chain. As far as I can see, the greatest concern is transction size. Going from 200 bytes to 50 kilobytes is simply not worth it.

What plan would that be?

You know ... the master plan ;)

Just kidding. It's more like how I imagine things playing out combined with the existing work that we're doing. Here's what I sent to the ZeroCoin guys when I reviewed their paper:

Okay, first, some specific comments I would like to make about other people's comments:


If I understand correctly, trapdoor params during accumulator setup do not give you the ability to "denanonymize everyone forever" - it does, however, give you ability to forge as much zerocoins as you can care, which is bad.
However, the paper mentions something called RSA UFO (It's right over my head. Badum-tish) that allows the developer to set up the accumulator without learning the "sensitive numbers" and thus not gaining any kind of anonymity-destroying or coin-forging "superpowers"



Unless I greatly misunderstand, it is not accumulator per se that is infinitely bloatable, but the "mint" and "spend" records that can't be pruned.
Which kind of sucks, unless some way to prune them without enabling double-spends is found.

As to storage, the article, if I understand correctly, specifies that the z-coin transactions can be stored anywhere, from blockchain to DHT to unicorns.

A bit of speculative commentary (IANAP/IANAC):

The article mentions that Schnorr group parameters can expire, and will have to be reset/regenerated, but states that it's not a problem since "oldtimer" zerocoins can be transformed into fresh ones.

However, I wonder if one could modify the constructs used so that old zerocoins will not be "transformable" into "new" zerocoins upon Schnorr group parameter expiration, thus unspent "oldtimer" zerocoins becoming essentially lost.

It might reduce convenience / anonymity (since you would have a limited time to spend the zerocoins) but since zerocoin is very explicitly an anonymous transaction system and not a value store, and since the "parameter expiration" can be pretty long in terms of human time and might even be leveraged to actually improve plausible deniability (script to spend all my zerocoins into bitcoins when expiration is near, as part of mainline client), it might be acceptable if it allows for pruning the z-coin DB (and why not prune records that are explicitly and irrevocably expired? )

Now, on to a more general (and more controversial ;D ) topic

At the risk of getting stoned (and not in a nice way), I would like to bring up a certain question:

Would it be wise to implement "stronger" anonymity in bitcoin ?

Bitcoin, as it stands, is strongly pseudonymous.

Under reasonably careful use, it has just enough anonymity to discourage causal peeping toms and minor LEA investigations.
Under very careful use, it can probably protect the user from a considerable investigative effort.
It is, obviously, not "absolute" though.

However, it not being "absolute" lends it properties that make it more backwards-compatible with existing monetary system, and more palatable to "average pointy-haired legislator" (and even despite not being all that untraceable, Bitcoin is catching some misguided flak as being a "criminal's currency")

Given that the seemingly apparent aspiration of the project (correct me if I am wrong) is to establish a widely accepted digital  "commodity money" that would be free from human monetary policy meddling and forced seizure (kind of like digital gold money), "hardcore no-holds-barred" anonymity might actually be counterproductive in the long term, since it would impede wide-scale merchant and institutional adoption (Many investors might choose to steer clear if you start signalling that you are, essentially, trading a "Los Zetas derivative" :) )

Current Bitcoin's condition of being "strongly pseudonymous" and "never forgetting" could be a sweet spot that gives average and above-average Joe just enough obfuscation to make invading their privacy too costly and time consuming while still being auditable enough to appeal to mainstream finance and large merchants.

Moving out of this sweet spot in any direction might be woeful.

Also, consider this - many investors who are currently "in BTC" (including people investing in expensive, complicated mining equipment like ASICs) have invested with their risk assessment being based upon understanding of bitcoin as "strong pseudonimity, moderate privacy" system.
By radically altering bitcoin's anonymity/privacy profile, one would be be voiding those people's assumptions regarding political, legal and regulatory risks and compromising their trust.


========

Disclosure:
I am actually a proponent of "absolutely anonymous" digital transaction mediums as a concept.

I am, however, dubious in regards to whether BTC should strive to become such a medium, given that it already has a notable investment, regulatory, and institutional infrastructure organized around a different set of privacy/anonymity assumptions.


========

Last part, ADHD version:

"Absolute" anonymity may have unforeseen regulatory, social, and financial consequences for "bitcoinomy".

Given that "bitcoinomy" is doing pretty fine with current level of "privacy/anonymity", it might be wise to avoid meddling with this property of Bitcoin.

It wont be anonymous once you start pulling it out

This has been asked before— and I think it's an important question. We shouldn't just assume that any feature is good.

After extensive consideration, I think I can answer this with an emphatic "Yes".  Without good anonymity the fungibility of Bitcoin can be substantially degraded.  The road to fungibility loss is paved with good intentions, but the end result makes Bitcoin less useful as money.   "We're really sure that _this_ bitcoin was stolen" ... "We're quite confident that this person is bad" ...  but if Bitcoin is to be trustworthy you must never have reason to feel that you'll wake up on the wrong side of a kafkaesq heuristic, or that you'll have to fight for what is rightfully yours even if there is due process, having to defend yourself means you already lost.

I believe that the ultimate social good that comes out of weaker anonymity for Bitcoin like activity is fairly limited: Bad-guys will generally figure out good ways around the lack of transaction anonymity, but still get caught based on their other activities even when transactions are strongly private. The harms from not having good anonymity— the losses of privacy, the danger to fungibility— hurt everyone.

Then there is the question of should it be in the system or outside of it.  If we ignore the implementation cost, I think here again the answer is emphatically that it should be inside the system:  Putting it outside greatly reduces its effectiveness.   But right now implementation costs are non-trivial and so I don't think there is much of a question of including it in the system—  and, if people build it outside of the system: we can't stop them even if we were to agree that it were a bad thing.
 

Bitcoin is only accountable because you typically have to put money into it to use it. Are the miners accountable? Could a miner be traced to his IP if he used his mined coin to commit a crime?

Yeah, this is definitely an important and interesting question. The not totally invincible nature of Bitcoin's privacy certainly makes conversations with LE a bit easier (I've had a couple of conversations with UK LE already and want to have more at the conference).

I think it's really important to understand that privacy and anonymity are not really the same thing. If I send money to or from Mt Gox, then I've probably had to go through KYC and I'm not anonymous to them (or you), but that transaction is still private - you can't find out I did it from the block chain. It might seem like an academic point but people have very different emotional reactions to privacy (good!) vs anonymity (scary!).

Bitcoin should seek to provide privacy. It's unacceptable that someone might earn their salary in Bitcoins and then have a colleague discover their income by analysing the block chain. That's actually the kind of privacy leak that tends to bother people most in their every day life, most people aren't trying to make an enemy of their own governments. But at the same time, we should make it easy for people to prove their identities to each other, mostly because this can help grease the wheels of trade. Zero trust protocols are great when you can make them work, but it's often quite tricky and taking personal legal responsibility for your actions is a model everyone is already familiar with.

The payment protocol takes us one step in that direction, it lets merchants identify themselves to customers if they want to and that's very useful for hardware wallets like Trezor that assume a compromised host. For person-to-person trades it's harder. Unfortunately governments have largely let us down here. Most governments don't issue convenient personal certificates/keypairs. Estonia being one country that's ahead of the curve. One of the things I want to explore is whether the RFID passports that have been issued over the last 10 years can be re-used outside of the border control system, I rather suspect the answer is no but it's worth checking out. I'd like to be able to sign my own payment requests with my identity so if the entity paying me has a malware infected host and a hardware wallet, they can still pay me successfully. I think this is a good point to bring up with governments - they insist on AML and strong ID verification but then insist on archaic standards like "scan of passport + utility bill", which is shoddy. If they're going to complain about Bitcoin then I think we have a right to complain about their lack of a real citizen PKI :)

Right now bitcoinj has woeful privacy, we've spent our time optimising performance and reliability of backups rather than that. But in future I'd hope we can make some of the improvements I listed above. It will help ordinary people a lot, and I don't think it'd make much difference to LE investigations. The thing that'd help them the most is people knowing who they're trading with, so they can try and "follow the money" by getting the relevant warrants for each step in the chain.

You're confusing your employer with humankind in general.

There isn't really a difference between privacy and anonymity. Rather the difference is between the weaker privacy from individuals spying on you, and stronger privacy from corporations and governments spying on you. Google's services tend to provide the former, but almost never provide the latter, and if anything usually make obtaining the latter much more difficult than it could be.

tl;dr: Anonymity is simply the strongest form of privacy.

1) I think that in vivo experiment known as the Silk Road demonstrates, convincingly, that "properly used Bitcoin" has very strong anonymity.

Yes, it is not perfect, but so far, a motivated and resourceful attacker appears to be unable to "dox" a major, publicly known pseudonymous player.

2) If your concern is fungibility, then Zerocoin-like systems - not just this particular implementation with massive proofs and pruning issues, but basically any system that requires formation of "fixed-denomination" non-fungible "tokens" with fixed BTC value - would not appear to be acceptable solutions.
Since they outright break fungibility

Besides, any system that involves special "anonymize me this 1.00 BTC" transaction types could hurt fungibility along the same lines as you describe (a cautious vendor might not accept a coin that is less than N transactions away from an obvious "anonymizing event")

Me?
I think that the problem of "banned coins" is more of a legal and social issue rather than a technological one.
And so far, bitcoin "ecosystem" has been handling this problem rather well, so perhaps it would be wise to refrain from fixing something that is, from available evidence, not broken.

So far, bitcoin has been choosing its fights fairly well, and gained a modicum of mainstream acceptance, including acceptance by regulatory authorities.

I am not convinced a "100% hardcore anon-coin" could enjoy such (even cash is relatively traceable, one doesn't even have to be a government to track a paper note (http://www.wheresgeorge.com/))

Also, there is the issue of  current investors and supporters  (miners, merchants, service providers) - many of them may suffer various degrees of inconvenience if bitcoin announces a "full anonymity protocol extension" since that might prompt their local authorities to take a much closer look at their business, which is something they might not entirely appreciate.

I am all for the world having a "full-anon decentralized cryptographic payment system".
But since I think such a system would have a harder time gaining mainstream acceptance, I am not convinced that bitcoin should be this system.
Perhaps bitcoin should stay strongly pseudonymous, to facilitate... how to put it... backwards compatibility with various regulatory bodies ? :)

Could you guys stop bringing Google up? It's both irrelevant and offensive - as if I don't have or don't speak my own mind.

Privacy and anonymity are absolutely different thing. It is possible to be anonymous and yet lack privacy. For example, if Satoshi cashed out all at once, we'd know this immediately even though we do not know anything about him.

I think you are confusing fungibility with divisibility.

gmaxwell's points about enhanced fungibility due to strong anonymity are correct ... and are not widely appreciated.

You are correct that fixed-denomination tokens are not as divisible, but this is a simple technical matter of choosing the smallest denomination that makes sense in terms of value. Eg. if we had system that dealt with strongly anonymous satoshis as the fundamental unit it would be functionally equivalent as a money to bitcoin as it is now.

http://www.reddit.com/r/ZeroCoin (http://www.reddit.com/r/ZeroCoin) is up and running for any interested redditors.

Are you involved with ZeroCoin directly?

Just to be clear, ZeroCoin is not going to be implemented in Bitcoin in its current form - it's just too inefficient right now. Don't get me wrong, it's a great idea and some great crypto, but it's a proof-of-concept and they still have a lot more work to do in making it efficient enough to be practical. It could easily be years before it can become a part of Bitcoin proper, if ever.

Creating a sub-reddit now is premature and just makes ZeroCoin look like vaporware to the general public.

You guys need to read between the lines.  The authors are in the awkward position of explaining a way to make Bitcoin anonymous. They need a way to say, "see this could be set up so that the government could audit it" because this provides the "moral cover" to prepare the research in the first place.

But if you read between the lines, they've released the method for making this without such a backdoor, and that's all that matters.

That's what it looked like to me also. It is a sad state of affairs when researchers cannot investigate new ways of doing things without the chilling effect of "what will the fed/govt think?" It seems even freedom of thought is under threat.

It's never to early to start a conversation.

Ah indeed, my bad - that's what I get for posting w/o caffeine  ;D

However, I do believe that part of my point still stands.

In any system where anonymity is achieved along the lines of
[classic BTC-style TX -> classic BTC-style TX -> "weird" high-anonTX ->  :-X ->  ??? -> classic BTC-style TX]

fungibility may start failing same way it could start  failing in BTC now.

Merchfolk could begin refusing to accept coins which appear directly related to the "weird high-anonTX"

So, when should we start to prepare for another hard-fork? (please please please make something like this happen?)

I'm actually surprised that something as prestigious as Johns Hopkins would even consider Bitcoin as an interesting idea, let alone have a research project to actively try to improve it. (they're a direct rival to my alma mater, too)

Why not ? Bitcoin is cryptographically interesting, and so is the challenge of "distributed anonymity" - I say prime JH material.

Yep this is correct.

It is not an easy problem ... excellent material for JH in other words.

I have read the papers on Satoshi (Bitcoin) and Miers (Zerocoin) but they don't seem to be published in any reputable conference. Is there any reason why or is it that there are no conferences for this type of research?

I actually did find the Bitcoin summary (Section 2) easier to understand than the original bitcoin paper by Nakamoto.

As soon as you stop accepting money from them, sure.

Nothing wrong with that, by the way.

But there is something wrong with trying to claim that you aren't influenced by your source of income.  Gavin and most of The Bitcoin Foundation explicitly disagree with that, citing it as one of the major reasons why TBF needs to exist -- to provide Gavin with a income source that isn't controlled by the profit motives of a single organization.

Look, I don't think you're going to get very far with "employers don't influence peoples' views" around here.  Try something else.

Your boss doesn't seem to think so.  He keeps telling people that if they don't like it they can just change their name (http://www.huffingtonpost.com/2010/08/16/google-ceo-eric-schmidt-s_n_684031.html), which is basically saying that anonymity (or pseudonymity) is the only route to privacy.

So maybe this is why you have a vested interest in convincing people they don't need anonymity or pseudonymity?  I mean, obviously if you said people don't need privacy nobody would take you seriously.  But it's a lot easier to tell people that privacy is okay as long as they don't have the means to establish it.

You don't have any idea how Google works, do you?

Firstly, Eric Schmidt isn't my boss and hasn't been for years. The CEO is Larry Page these days. But even if he was, a throwaway "prediction" intended to provoke discussion from 3 years ago is not very compelling evidence for your point of view.

Secondly, my job for the past few years has been anti spam and nothing to do with Bitcoin. I've been allowed to work on it under the 20% time policy which is very hands-off. My management have never told me what to do or what positions to take on anything with respect to Bitcoin. My compensation isn't affected by anything I do here.

Thirdly, I don't have a "vested interest in convincing people they don't need anonymity". Why would I spend so much time working on a project created by an anonymous founder if I had a problem with anonymity? But I'm also a realist. Go talk to people in the world outside this forum echo chamber for a while. There are a LOT of people, especially older people, who are immediately very suspicious of anyone who is anonymous or uses a pseudonym. You can see similar concerns come up in the media coverage - trusting mathematics instead of people is just a totally alien way of thinking for most people. Whenever I've explained Bitcoin to my parents the thing they fixate on is "Why is the guy who made this anonymous? Why do you trust this thing he made?". They eventually came to understand that it didn't matter who he was, but even after I explained that for the Nth time, they still have an allergic reaction to it. Why? Because the most common reason for people to hide their identity is to avoid the justice system.

Anyway, you haven't got my point at all - privacy and anonymity are linked but are not the same. Satoshi's paper says as much:


Neither banking nor Bitcoin provides perfect privacy or anonymity. Banks give users privacy from each other but obviously the banks and governments still know what you're doing. Bitcoin users have no authority that knows everything but routinely leak private data to each other by misusing the block chain (re-using keys, etc).

I've watched the presentation of the paper http://research.microsoft.com/apps/video/dl.aspx?id=192058 and I have one important question. First off, I'm actually an academic in computer science, but the zero-proof subject matter is all rather new to me.

So the question:

If I make a zerocoin and later want to to redeem the zerocoin back to a bitcoin what is the reason this cannot be traced back to the specific zerocoin I'm converting back to Bitcoin (and in effect my previous Bitcoin transactions)? In the talk Matthew Green mentions that proof is required to show you own the zerocoin. Why doesn't this imply this whole system isn't anonymous at all?

If anyone can explain this, thanks a lot :)

PS: As the first half hour was really slow and simple to follow for the uneducated I hoped he would continue with this when he reached the difficult cryptographic portion of the talk but then he went into overdrive not even introducing the concept of an accumulator. He could have skipped the first half an hour for me and took twice as long for the second part for me, but it must have been on a cryptography conference or something.

You can't trace the proof back to the specific coin, all you can see is that to a high degree of probability the person redeeming the zerocoin possesses the secret trapdoor associated with one of blinded coins.

Okay, is there a way for me to comprehend this without venturing into the world of digital commitments, one-way accumulators and zero-knowledge proofs? I mean, I can explain the inner working of Bitcoin to quite a level of detail (at least to anyone with a technical degree) before someone has to take my word for it. Is it possible to explain how I can prove I own 'some unredeemed Zerocoin in the blockchain' without specifying which one without a PhD is cryptography?

I want to believe but I need to be convinced I guess ;)

Yeah, I'm afraid you would have to delve into zero knowledge proofs. There are some good papers on the internet, but I can't say I fully grasp how it works just yet.

Haha, well thanks anyway.

Btw I made a summary of the zerocoin paper here.  

http://www.mail-archive.com/cryptography@randombit.net/msg04117.html

Not sure it helps understand it or not, but there you go.

About ZKP of set-membership the first thing to understand is the RSA accumulator of Benaloh.  

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf

Its like a commutative hash function but using RSA.  With discrete log (or EC discrete log) if i give you A = xG (G is base point x some random number) I can prove I know the discrete log by showing you x and G is fixed.  But if you are allowed to use any generator H then you can start with A divide it by some random number x and call the result H.  Now you can prove xH = A but that doesnt prove anything as anyone can do that if they can prove the discrete log to some random base its an x-th root not a discrete log, which is easy .  How you "divide" A by x is multiply by x^-1 mod n (n is the order of the curve a public known value for a EC parameter set).  And you can compute x^-1 mod n easily with euclidean algorithm (normal modular math, no EC).

However the analogous division is not possible with RSA, in RSA computing x-th roots is also hard (as well as discrete log).  eg If I give you A you cant compute A^(x^-1) because x^-1 has to be mod phi(n) = (p-1)*(q-1), and in the case of RSA phi(n) is secret and in the case of an accumulator p, q, phi(n) are supposed to be deleted after setup so no-one knows them.  So if I can show you H and x and H^x = A that proves you I had an influence in producing A.  

each step is done by the user after receiving the previous accum set.  Users can go in any order as exponentiation is commutative.

G and n is published, p, q deleted
step0: accum set = {G}
user1: private x1, accum set = {G,A"=G^x1}
user2: private x2, accum set = {G^x2,G^x1,A'=G^x1^x2}
user3: private x3, accum set = {G^x2^x3,G^x1^x3,G^x1^x2,A=G^x1^x1^x3}

The accum set is broadcast by each user and each user raises every element except the last to his private exponent xi, and appends the last element raised to his private exponent xi.

You notice that the base of each user is missing the exponent of his respective xi, user1 base is missing x1 (first item in set), user 2 is missing x2 (second item in set), user 3 is missing x3 (third item in set).  Consequently a user can raise his private base call it Bi for user i, to power xi and get A the global accumulator Bi^xi = A.  Because discrete log and x-th roots are hard in RSA he cant do that unless he was involved in this process.

That involves a lot of sending of sets.  If alternatively each user broadcasts his xi, everyone can compute his own Bi and the final A, however now anyone can compute any Bi and all xi are public.  Its a lot more communication efficient however.  To combat the fact that xi are public, xi has to be chosen eg as xi = H( yi ) where yi is secret.  Then a user can prove that by revealing yi and having the verifier check xi = H( yi ) and Bi^xi = A.

Or as its hard to efficiently make ZKP about (symmetric) one way hash functions a discrete log "hash" function could be used eg xi = H^yi.  Now the user could prove knowledge of yi without revealing yi (via a Schnorr signature see below).

So lots of people compute and pass those messages around then they can prove simply that their zerocoin is in the set until there is a final A that includes contributions from all users who produced zerocoins in this time period.  And each user knows a Bi such that Bi^xi = A for the single A value so they can prove membership.  The order is commutative so it doesnt matter which comes first.  A is small - just 2048 bits = 256bytes no matter how any serial numbers are provable against it.  Bi is also small 256bytes as well as is xi.  And the user need only store Bi and xi because he can compute A from it.

So that provides a proof that you had an influence on an accumulator (some non-secret value of yours was included "hashed" into an accumulator).  Its rather like a merkle tree except that you dont need to provide log n path in the three to prove, just prove you know Bi^xi = A.

So far thats not private as all Bi values are recognizable to anyone who saw them.  However using an extended blind schnorr signature like proof where you can prove you must know such an xi and Bi without actually revealing them.  Its ZKP because the verifier could even create a fake if he choose the challenge himself so therefore you can argue he couldnt learn anything about Bi nor xi from something he could've created yourself.  

A schnorr proof of knowledge to get an idea how you could prove something similar is related to a DSA signature and relatively simple eg here.  http://en.wikipedia.org/wiki/Schnorr_signature and its the same concept as DSA, ECDSA etc - ie you can prove you know the discrete log of something, without actually revealing the discrete log!

A schnorr proof only hides xi, the zerocoin enhanced proof also hides Bi but the basic idea is the same.

The efficiency problem in zerocoin is that each run of the ZKP has a 1/2 chance of being unconvincing.  So you have to run it like 128-times to get probability 1/2^128 kinds of cryptographic assurance.  This repetition is called cut-and-choose.  Fortunately it can be made non interactive (by fixing the challenges based on a one-way hash of the parameters), but thats still 128 x 2048-bit RSA things which is like 10s of kB.  Probably they are doing a bit less than 128 cut-and-choose rounds because they say that proof size is 45kB for 2048-bit and I presume a proof includes at least 2x 2048-bit values.  Actually I see they say 80x, so that comes out to 2.2 so maybe there is some auxilliary info, eg the serial number?

To prevent double spending they just keep a public list of spent zerocoin serial numbers, and you cant influence the serial number after the fact.

So I guess the other thing you can do if that is unnecessarily complicated is just say ok there's a ZKP of set membership which proves your coin is one of that set, but not which one and trust that people have figured out how to make that work.

btw Benaloh's accumulator paper is quite readable

[edit: fix error about xi vs Bi and give a small example]
[edit2: more communication efficient public xi = H^yi, secret yi or xi = H( yi ) version]

Adam

So one thing you could think of and I think it has been mentioned a few times is that you could replace the merkle tree in bitcoin with an accumulator based tree.  Now a problem with accumulators is someone or some set of n people only 1 of whom has to be trusted, have to create n = p*q two primes p, q and then delete p, q; which is not great but could be entertained perhaps if accumulators made some big saving.

Consider accumulator hashes: then an SPV client can be convinced a coin is in a block by receiving Bi and xi.  Each Bi is 384 bytes (3072bit RSA n is about the same security margin as the rest of bitcoin, considered about as secure as 128-bit symmetric keys and 256-bit EC keys).  Then a proof of membership within a block is 384 bytes + the hash say 20 bytes + the transaction detail whatever that is a hundred bytes say 512bytes.  

The merkle tree approach requires log2(k) hashes each 32 bytes, k the number of transactions in a block.  I guess a block could hold ~10,000 transactions best case with 1MB blocks.  However this page https://en.bitcoin.it/wiki/Scalability says transactions per second is currently limited to 7 = 4200/block.  log2(4200) ~12 and 12*32=384 bytes.  No saving for accumulators!

However another trick could be to not start a new accumulator with each block, just keep going, then you only need the last block in the chain.  (SPV clients download all blocks, or some set of recent blocks for confidence?)   So with accumulators to catch up an SPV client just download the latest block, cross-check a few peers agree its the latest block.  However someone (each full node?) would have to update Bi for all unspent coins.  Updating Bi is a 3072-bit to a 256-bit modexp operation which has some cost.   That might start to get unreasonably CPU expensive, unless the network shares out the work.  The benefit would be faster catchup for SPV clients.

I suppose alternatively blocks themselvs could be placed into a sorted merkle tree, and then SPV clients could download blocks as needed (log2(b) blocks where b is 23866 blocks so far http://blockexplorer.com/q/getblockcount) ~15 blocks to test a given block.  But its probably not a big saving because transactions are made from multiple outputs and an SPV client if it does a few transactions per day will soon have to download all blocks anyway.

Or you could have an accumulator tree of blocks, with the accumulator hashed in the latest block.  Then you can download any historic block and instantly check it belongs in the history of the current block without downloading the rest of the block chain, nor 15 blocks for log2(b) verification if the block were organized as a merkle tree.  Cost is each full node needs to update (or fullnodes cooperatively update) the Bi values for all 23866 blocks every block (10mins).

Some possibilities in there but nothing very impressive, plus the problem of there temporarily existing an accumulator private key that must be deleted (spread across the RAM of n users during accumulator genesis/generation, only one of which needs to be trustworthy).

Adam

I've started and then stopped writing about Zerocoin three or four times now; my thoughts about it are still muddled.

It adds a whole lot of complexity to transaction creation/verification to solve one problem:  how to mix coins/transactions with zero trust in the mixing process.  That's technically nifty, but I wonder if it is the best engineering solution.

I wonder if just using a couple of semi-trusted mixers would be a lot faster/smaller/simpler.

And then I start thinking about "tainted coins" in general. If we imagine a world with either mandatory or voluntary "taint tracking" (I have no idea whether or not that will ever happen), then it seems to me any mixing scheme that isn't "always on" is likely to fail in practice-- all coins coming out of the mix will be considered tainted.

Why? I assume that most users (if you are reading this are NOT "most users") don't care much about privacy/anonymity. So I would assume most people would choose the lowest cost, fastest, most convenient method for their transactions. Anybody using a mixer will be either a weirdo, principled privacy nut (like us) or a criminal. I don't see other "privacy first" projects taking over the world, but do see lots of big, successful "quick and easy and free" projects.

Then my thoughts get muddled, because "it is hopeless, just give up" is not an answer I'm willing to accept. But it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer. Making your network connection more private is the other piece of the puzzle, though, and all of the solutions for that (either route through a couple of semi-trusted proxies or use Tor or i2p) add significant convenience/speed/financial costs.

I have a feeling that anything on this front that will work in the end will:1. require no change to the code of the Bitcoin client;2. interoperate seamlessly with the current infrastructure;3.have adjustable level of paranoia/usability ;4. backed by competent and transparent developers.

my thoughts in response to "doubting gavin's" post:

i think this idea has merit for these reasons:

Today taint is irrelevant for 99,99% of transactions. if someone tips you would you go back and try to trace that and will you try to "remove" that money from your wallet? i guess not. likewise most payment processors would not care. i don't know if mtgox performs any checks, but i would guess yes.

it improves fungibility of coins - if a block includes a valid input it should not matter where they come from. having zerocoin out there working removes all doubt about fungibility and "solves" this issue.

I see many valid use cases why someone would love to use zerocoin.

Just one example: in the year 2023 Gavin and family want to go to vacation to Mexico. Books a 4* hotel for 3 mBTC for two weeks using his desktop wallet.
The wallet of the hotel is of course a HD Wallet where Los Zetas control the master private seed. Thanks to trivial blockchain analysis and entity merging they are informed that someone with 10+ Bitcoins *gasp* is coming, and know their exact location and time.

Once he arrives access to his wallet is obtained via rubber-hose cryptanalysis.

If there was Zerocoin you could trivially create a "holiday spending" identity it would be very hard to estimate someone's net worth in bitcoins just by obtaining one transaction. Put 10 mBtc there and have two nice weeks.


Yes the proofs might be large and therefore most transactions would be expensive - this is why fees are calculated by KB. i would say, we should let the a free fee market decide if it is worth using and worth of inclusion in blocks.

hopefully we can explore this interesting topic further reducing the overhead further. i am still trying to understand the details of how it works but so far - i think it is absolutely worth including something like zerocoin into the mainline client, once we have a "good enough" solution.

Yes I had the same thought - seems awfully expensive for a mix.  You can view zerocoin as a private keyless p2p mix.  Several people have proposed non-p2p mixing protocols where the mix cant steal your coins.  Whats wrong with that?  I guess the main limit is the mix disappears and your coins get locked.  Probably that could be fixed with smart contracts/multisig.

Greg Maxwell also and others proposed taint mixing using multiple coin inputs.

(Other than mixing you may also aim to taint all, equally as a protocol).


I agree that is likely the end game for mixes.


The committed coins idea that temporarily keeps the taint decision private allows people to at least retain p2p decisions about taint without any a priori restrictions.  However the privacy is either short-lived (fairly immediately decommit the coin) or the privacy shrinks over time (if you keep spending the coin in committed form) as more people get to see the transaction history, as each recipient must see all details prior for validation.  A posteriori sanctions after decommit may come into play to if the user is identifiable - if your IP address is logged as posting the reveal of a tainted coin, maybe that matters also.

Fairly efficient/low overhead but still some limitations there.


It seems like users who are doing high value bitcoin things should be using ToR to hide their IP address which geolocates them.  And servers also should to add resistance to network split types of attacks.  Maybe in a 2.0 bitcoin it might include the minimal defenses of encryption, tunneled relaying and hard to influence remote connections for double-checking local claims.

Adam

I have a weird question...what happens to password protected wallet of dead person or person who forgot his password? Are these bitcoins lost forever?

this question does not really belong to this thread because exactly the same happens with zerocoin or without.
if you lose the password of a protected wallet and it is the only backup - the money is gone. with zerocoin or without.

Whats taint?

Not sure what's the proposal that you have in mind, I remember others talking about such ideas in 2011 in #bitcoin-dev (link (http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/07/22#l1331355)), and these ideas could be a lot more efficient than using ZK proofs.

I believe that the idea is that instead of how blocks are created now for the blockchain, the network nodes will create "mixed" blocks in 3 rounds of communication, instead of 1 round. Suppose Alice wants to send 5 bitcoins to Bob, Carol wants to send 4 bitcoins to Dave, Ellen wants to send 3 bitcoins to Frank, and we now wish to construct the next block with these three transactions. So in round 1 Alice broadcasts a message that declares that she intends to send 5 bitcoins to Bob's address (without signing this message with her privkey), and Carol and Ellen do the same. Now in round 2 the miners prepares a single transaction with the inputs of Alice,Carol,Ellen (12 bitcoins in total) and the outputs of 5 bitcoins to Bob's address, 4 bitcoins to Dave's address, 3 bitcoins to Frank's address, and broadcast this single transaction. In round 3 Alice signs this single transaction and broadcasts her signature, and Carol and Ellen do the same. Now the miners can do PoW work on a block that contains this transaction, and finally broadcast the valid block that they solved. This way the block is created in a mixed fashion, in the sense that the data that resides in the blockchain doesn't specify whether Alice's (possibly tainted) coins were sent to Bob or Dave or Frank. After iterating this same process with the next blocks, it would be practically impossible to tell where Alice's tainted coins ended up at. An attacker can eavesdrop on the network and know that Alice sent her coins to Bob, but he cannot prove anything because Alice's message in round 1 isn't signed and therefore can be forged by anyone.

Problems with this idea:
1) Alice must send a fee as a secondary signed transaction in round 1, otherwise if Alice is malicious then she could refuse to participate in round 3 to carry out a denial of service attack, because the single mixed transaction is valid only if both Alice and Carol and Ellen sign it. On the other hand, malicious miners could now collect fees without including txns in blocks. Maybe it can work if the fee in round 1 is smaller than the fee that Alice would pay for the actual transaction where she transfer her coins Bob, so the miners will have an incentive to generate non-empty blocks (i.e. not to generate blocks that contain only the fees of round 1) ?
2) When the miners are working on the PoW, if other transactions (with high fees) were broadcasted in the meanwhile, then in order to include the extra transactions they'd have to prepare another single mixed transaction (because the signatures for the first mixed transaction have already been provided). So it appears that this process will work in batches, where a block could contain several such mixed transactions. We should be careful that the default behavior of nodes is to prefer signing mixed transactions with many inputs, otherwise malicious miners could attempt to reduce the overall privacy.

Any suggestions on how to improve this idea?

Edit: Looking at another thread (link (https://bitcointalk.org/index.php?topic=93390.msg1036406#msg1036406)), I see that here too we'll have to do the knapsack-style random value splits. I suppose that it means that Alice should request several receiving addresses from Bob before she sends her coins to him? Or maybe just one pubkey and chaincode, if Bob is using type-2 deterministic wallet.

Could we simplify this by creating a new hash type combining the effects of SIGHASH_SINGLE and SIGHASH_ANYONECANPAY? It would mean "as long as my output is included, I'll release my input". A further step would be to require valid blocks to consolidate all such transactions into a single transaction.

Maybe this could even be combined with homomorphic encryption to obscure the incoming amounts and to consolidate chains of transactions? The combined effect would be netting of transactions with obscured incoming amounts.

Hmm, on reflection, obscuring couldn't work, because you do need to know which inputs are now spent. Netting of successive transactions might still work.

Hmm, on further reflection the SIGHASH_SINGLE + SIGHASH_ANYONECANPAY idea might not work either. It seems to me that either SIGHASH_SINGLE is somehow linked to a specific output, in which case it doesn't help anonymise transactions, or it is unsafe, which isn't helpful either. I guess I'll have to read up some more to see if anything can be salvaged from my suggestions.

Greg also said something like that:

https://bitcointalk.org/index.php?topic=139581.0

but as a multi-user/multi-input transaction to complicate simplistic tracing taint back to a the owner on the assumption that all inputs from spends are from the different addresses of the same sender.  So in that case there is no unsigned input statement, just a multisig with multiple inputs (from a variety of people) and multiple outputs, so there's not really any doubt about who put money into the mix or who took money out (presuming each person takes out what they put in), just that any tracing identities has to account for this existing mixed owner inputs possibility.

You could view the version when all the transactions in a block are mixed as something like zerocoin except with a fresh anonymity-set for every block.  And the output goes directly to the recipient which I guess could be done with zerocoin also (put recipients address rather than your own on cashing out of the pool).


Interesting but limitations with DoS vulnerability & also multi-round.  Also presumably if the amounts are uneven you can pair spends and change amounts that match to inputs, and conclude one is the recipient of that sender and on the change to self.  However I see that's what the ref to a post by Mike Hearn was about, splitting the payments to lot of keys in small enough payments to create ambiguity.

https://bitcointalk.org/index.php?topic=93390.msg1036406#msg1036406


Towards a more efficient solution, maybe we could use a ring signature scheme so that groups of users can spontaneously form groups, and sign on behalf of the group without revealing which user they are.  (Ring signatures are like 1 of n multisig but do not reveal which user signed).

When all the outputs are group signed, the users sign their respective inputs to fund the transaction and publish it.

http://people.csail.mit.edu/rivest/RivestShamirTauman-HowToLeakASecret.pdf


That same set of users can then sign (with normal ECDSA) the inputs to fund the transaction.  Doesnt completely solve the DoS problems, but you cant just spam you have to join or be elected as a group member by the initiator (just one user).  The process of choosing which users will be in the group is flexible from the ring signature perspective - the other users dont even have to cooperate.  The ring signature concept was extended by others to cover DL based signatures (and EC) so I think you could simply enough add ECDSA ring signatures.

The point is you dont want to know who proposed each output, but the inputs have to be signed to release the funds.  And yet you dont want a spam free-for-all of proposed inputs, the ring signature keeps the proposed outputs unidentified as to which user proposed them.  The sender retains control however as he wont sign the input unless the outputs match the requirements of his payment and change.  The group setup doesnt need to involve the miner in this way either so everything can be done in one round.

[edit] btw the ring signatures are exceedingly computationally efficient, barely any more than the underlying signature in the case of Rivest's and its actually a simple concept here's a simplified example RSA ring signature: something like if an RSA signature is presentation of a s=H(m)^d then a simplified 2 user ring signature could be eg s1,s2 where s2=r and s1=(H(m) xor r')^d, r = random, r' = r^e then to verify the verifier calculates s1^e=H(m) xor r' and s2^e = r' and test with (s1^e xor s2^e =? H(m)).  Now you cant tell if s1 or s2 is random, and so it could have been signed by either person.  The other person you implicate in this "could have signed" game doesnt even have to participate, but the verifier and anyone can be convinced that the message must have been signed by one of them.  (Technically r is an existential signature forgery of "message" r'.)

Adam

Wikipedia article about Hashcash has the next line "It [Hashcash proof-of-work system] is also used as the proof-of-work protocol in Bitcoin" Wiki:Hashcash (http://en.wikipedia.org/wiki/Hashcash), which was added by you on November 2012. I think you have quite an ego considering there is no much similarities between the two apart from the name.

Adam is justifiably proud of Hashcash, and it was an important influence on Bitcoin.

Only Satoshi can tell what kind of influence it was, do you have any quotes? If you compare technical details of those two systems then it's like computer vs abacus (http://en.wikipedia.org/wiki/Abacus)

Adam very well was in a position to be Satoshi - bitcoin is just a different application of the same technical ideas. I will take his word that he is not. If you want to debate it, you should probably do it somewhere else.

Taking a leaf from Meni Rosenfeld  https://bitcointalk.org/index.php?topic=121314 I figured I'd create a thread for people such as Serith (and he seems not alone) to dis me in. 

https://bitcointalk.org/index.php?topic=225463.msg2371674#msg2371674

Go for it :)


And now back to the ring signature sub-thread.  Ring signatures and accumulators are closely related with the convenient exception that ring signatures are directly anonymous (not requiring a ZKP of set membership like zerocoin and Sander & Ta-Shma's auditable electronic cash that predates zerocoin in its auditability.)

Most of the ring signatures are however also not compact (with signature size linear in the number of members of the ring).  With bitcoin thats the anonymity set size, analogous to the total number of zerocoins so in any real use thats probably worse than zerocoin.

This Shoup ring signature however has a small constant size:

http://www.shoup.net/papers/subring.pdf

(trying to decipher now) however it is based on an accumulator and sigma-proof (ZKP) not figured out how efficient that proof is yet to understand if its better or worse than zerocoins set membership proof, nor even if it could be directly used (membership proofs dont have to prevent multiple-uses, zerocoin does).

Adam

Call me crazy, but if the algorithm is able to determine that you own the blinded coins, couldn't you in effect determine which blinded coins? By just doing the proof of work for each mint? And just use that to connect the dots?

The ZKP in zerocoin is able to prove you know a w and c such that A=w^c (where w=witness, c=commitment/coin and A is the global accumulator value at a given point in time) without revealing w and c.  c has the form c=g^s*h^r where s is the coin serial number (revealed) and r is a random number never revealed.  c=g^s*h^r is a pedersen commitment, you can think of it like a hash function c=H(s,r) in that its hard to find either s or r (because it one way).  Also its collision resistant so its hard to find another s,r value eg to find g^s*h^r==g^s'*h^r' even if you know what s and r are.  That like symmetric hash function also hard to find H(s,r)==H(s',r').  The difference is pedersen commitments involve algebraic operations on big numbers and the hardness of discrete logs and so are easier to prove things about (ie because you can usefully multiply them etc - hash functions like SHA256 just make a big mess of their inputs to achieve collision resistance.)

So putting that together zerocoin have a ZK signature of knowledge ZKSoK[tx]{(c,w,r):A==w^c and c==g^s*h^r} ie c,w,r are not revealed, tx is the transaction that is revealed and signed by the zerocoin spend/signature (eg tx = spend this zerocoin to this bitcoin address), s is revealed and stored and is the serial number that is recorded to avoid double-spending.  ie combining it shows that A==w^(g^s*h^r) and they were able to find a somewhat large way to prove that without revealing c,w,r.  Its large because it involves multiple cut-and-choose rounds as each round is only 50:50 convincing that what the prover claims is true.  After 80 rounds its security is 1/2^80 which is quite good.  (Though bitcoin aims for 2^128 which is more, they only used 80 to save space - 40kB was already unfortunately large for the zerocoin spend ZK "signature".

s is revealed and is the coin serial number, so its important that r is not revealed otherwise anyone could calculate c=g^s*h^r and just scan for that in the list of zerocoins de-anonymize the coin spends .  Fortunately because of the collision resistance of the pedersen commitment (hash function) not even the owner of the coin can create different s, r equal to the same c so he cant get two coins from one that way.  But to prevent the owner of the coin creating c=g^s'*h^r' * g^s * h^r and then proving two separate coins (and that would work because A = u^(c1*c2 *... cn) for all zerocoins ci) they further require that c be a prime number.  So you're not proving its prime via the ZKP when spending, but you are proving it when you create the zerocoin - all the miners check if c is prime (as c is revealed at that point).  So thats why c is prime.  (I had to ask Matthew Green that it was puzzling me as making c prime is moderately expensive, and why it takes 0.5 - 2 seconds to just create a zerocoin, and the Camenisch and Lysyanskaya paper the zerocoin accumulator comes from uses c prime only for  different reason that zero coin doesnt need - membership deletion).

It seems counter-intuitive that you can prove things without revealing them but thats what ECDSA does too - it proves that the signer knows the EC discrete log.  Its basically because you can see that only someone who knew the discrete log could have computed the signature, and yet anyone can see that the signature is valid.  The ZKP is the same just more complicated.

Adam

thank you for that concise explanation. i think i am 70% "there" to understand the basic properties of zerocoin.

can you elaborate or give links on the operators "^" and "*" is this the actual power and multiplication? then how can c be prime if it is defined as a multiplication of two powers?

Sorry if this is somewhat off-topic, but could OpenTransaction's off-chain transactions and blind signatures help with this at all? (even though it would depend on some third party running an OT server)

OT already have its cash-only mode which is as anonymous as it gets.

The point of ZeroCoin, AFAICT, is precisely not to depend on a server and just use the blockchain to achieve the same result. (I confess I haven't read ZeroCoin's paper and I have no idea how it works)

[edit used sup and sub for exponent and subscripts]
^ is power modulo some prime or RSA modulus depending on the situation and * is modular multiplication.

So the A=u^{c₁c₂...c_n} is modulo N an RSA modulus N=P*Q two primes P & Q.  A is the accumulator.   Note c₁c₂..c_k gets pretty big as users cant reduce it as they dont know phi(N) = (P-1)(Q-1) - no one does as its deleted after parameter generation.  u is some fairly chosen quadratic residue (square numbers mod N) ie there exists u' st u=u'² mod N.

This is the P & Q where you unfortunately get to trust someone to delete them.

Next for each coin c=g^sh^r mod p, where p is a fixed prime (not the same prime as P) actually a strong prime (where p = 2q+1, or even p=2^wq+1 for some integer w, to get a smaller q).  Because c=g^sh^r mod p c can be prime ie g^sh^r is clearly not prime by definition (it divides by g, h, g² etc) but g^sh^r mod p can be prime.  It quite a bit of work of trying random commitments to find a prime c though.  I tried coding it in openSSL and it wasnt that fast eg c=g^sh^r check if its prime, if not c'=c h mod p (so that c'=g^sh^r+1 mod p) and repeat.  Prime density is not so great at those sizes.

g and h are two generators in the shnorr group of size q.

So its curiously using two completely different groups - an RSA group for the accumulator and a Schnorr group for the pedersen commitment sounds odd but it doesnt really matter they are independent.

Now you can easily choose a c with two commitments in it (trying to get two zerocoins for the price of one bitcoin): prime c=g^s₁h^r₁ g^s₂h^r₂ mod p=g^s₁+s₂h^r₁+r₂ mod p.  

However to cheat and prove/spend two separate witnesses and zerocoins paid for with one bitcoin you need to prove you know A=w₁^c₁ mod N and also A=w₂^c₂ mod N with w1=u^{c₂c₃...c_n} mod N and w2=u^{c₁c₃...c_n} mod N.  However A=u^{c c₂c₃...c_n)} mod N because we paid for zerocoin c with our bitcoin.

So the only way to cheat is find c₁,c₂ such that c=c₁ c₂ or c=c₁c₂ mod phi(N).  You cant find c=c₁ c₂ because c is prime.  And you cant find c=c₁ c₂ mod phi(N) because you dont know phi(N) = (P-1)(Q-1) because P & Q are deleted during zercoin genesis.

If you could find such a c₁ and c₂ you would have found phi(N) by definition, and using that you can factor N trivially - ie thats impossible unless you can break RSA.  (You need phi(N) because you have to reduce the exponent by phi(N) with RSA ie A = u^c₁c₂ mod N = u^c₁c₂ mod N = u^{c₁c₂ mod phi(N))} mod N.

Now if you did know phi(N) = (P-1)(Q-1) you could clearly create multiple zerocoins for the price of one bitcoin.  So thats the trust in the person who sets up the value of N during zerocoin genesis.

Adam

Adam : any chance you can get that stuff into Latex or some equation displayer ... my eye's are allergic to math with ascii text :(

One way is to write them at this site
http://www.codecogs.com/latex/eqneditor.php (http://www.codecogs.com/latex/eqneditor.php)

... and link them into the text here either as gif or html if the forum supports it.(bit hacky but it works)

You should actually read Satoshi's paper before getting involved in such arguments. Adam's work is cited directly:


See section 4.

And yes, discussions about p2p mixing are quite old, that thread I'm quoted in is from July 2012.

I'm not sure Gavin is correct when he says ordinary people don't care about privacy. They care very much, hence the proliferation of scare stories in the media, the success of Facebook over MySpace, etc. That doesn't mean people will go to any lengths to get it from any and all parties though. Not all privacy adversaries are created equal.

I thought Gavin said ordinary people don't care much about anonymity. I'm not sure I concur, but it is a valid and important distinction between privacy and anonymity. With the right tools bitcoin does well with the former. Zerocoin addresses the latter.

You can get privacy without anonymity, eg as with the committed coins idea https://bitcointalk.org/index.php?topic=206303.0, only the sender and the recipient get to see the coins and who is spending to who.  (Unfortunately the committed coin privacy is not ideal because later people in the transaction chain of committed-form respends necessarily have to learn all previous details for validation reasons).

Some of the privacy focused ecash systems distinguished between payer anonymity and payee anonymity.  As a buyer you dont necessarily want all your payments to allow the public, the (ecash) bank nor the merchant to track which say ebooks you are reading.  It none of their business.

However the usual argument to blackmail crime scenario is that the criminal cant do that if there is only conditional payee anonymity (ie the spender colluding with the ecash bank can identify who the receiver is).  In bitcoin there is no bank to collude with, but you could imagine arbitrators in that role, or that the payee is identified to the payer (but no one else).  And of course the identify the recipient ignores identity theft, and assumes criminals are mindless non-adaptive automatons so its a fairly weak argument IMO.  In any system that strips privacy, the people who suffer loss of dignity and privacy invasion are the normal users, the criminals can still get privacy via identity theft, fake identities, buying fake identities from corrupt employees of government id issuers etc.  And criminals still launder money en-masse even with regular banks.   HSBC which reportedly laundered $880m of significantly dirty mexican drug cartel and even terrorist money and faces a $1.9b fine.  http://www.guardian.co.uk/business/2013/may/23/hsbc-court-threat-money-laundering-charges  Probably HSBC are going to walk away with the fine only (too big to jail despite the posturing).

Another possibility is it would be technically possible for the spender to be convinced who the recipient is without being able to prove it to other people eg with a ring signature, non-transferable signature, or designated verifier signature (the spender being the designated verifier).

Being able to sell things anonymously is a different and actually separable feature.  But people have also made pretty convincing arguments about why individuals should have the right to retain privacy while selling physical or virtual goods in a free society.

But I do think bitcoin ideally needs to find an efficient way to fix the fungibility problems with taint.  Payer privacy without payee privacy might not fully fix that as a payer who claims he didnt make the payment (claims the thief made the payment using the victims wallet to the thief) the victim would then identify the recipient.  If there were identities separate from coin addresses, you could imagine payee/recipient losing privacy on payer complaint, without the payee losing ability to make further payments with payment privacy.  ie the payee is expected to repay the value, not that the coins themselves become traceable.  However even then when identity is some random public key with no certification, its really not much of a threat to burn an identity.  Fidelity bonds perhaps are closer to network identities with some cost to losing.

Even in the physical world with conventional banks, once non-petty criminals are involved "identifying the perpetrator" becomes a fuzzy and useless fig-leaf fast as they identify a victim, or a fake identity bought from a corrupt government employee, or dupe the issuer - the RA stage is usually inherently pretty weak.  Criminals rent identities (money mule), buy or create fake identities, shell companies etc.

Finally to note a payment system could obviously have emergency tracability added to it as noted in the zerocoin paper.  Its typically easy technically to selectively weaken a protocol.  The problem is if you want it at all, you want emergency tracabiliy to be restricted to genuine emergencies, not drag-net fishing, not tracing of petty crimes.  Law enforcement are not always so clever about drawing lines there so you get mission creep until jay walking is an emergency.  eg in the UK I read a local council abused crime surveillance cameras to trace people who were bending the rules about which area they lived in to get their kids into a better school!  Next up people not pooper scooping their dog.  You know those things were weakly approved by society for terrorism clean up and maybe, arguably, serious organized crime.

Some ecash crypto papers have talked about system limits like payments are fully untraceable if they are under some amount (eg $10k like paper cash reporting limits) or under some amount per day per user.  Another limit can be the "emergency" access is limited to 1% of traffic period, more is not cryptographically possible.  Or I think alternatively and more simply access requires cooperation from involved users would be a nice balance.  Everyone has to transact with someone, and most transacting parties have no particular interest to protect some organized crime activity that rented a server or car from them.

Anyway the whole thing is a big mess.  And it's hard to maintain binary fungibility in the face of grey fuzzy privacy/traceability, and court ordered mission creep.  Computers do binary well so to me that is the natural physics of crypto and p2p virtual payments: irreverasable is cheaper than charge-backs (cash over credit cards), and there is no partially irrevocable.

Probably in an actual free society, people would understand that more people being killed by furniture falling on them than by terrorists should be sort of factored in in terms of spending and focus, and societal balance.  Obviously the people charged with cleaning up and infiltrating these things are too involved for perspective, but they work for society not the other way around.

The UK had its share of history with IRA blowing various stuff up, the US news typically in that era referred to the IRA as freedom fighters, some US factions even funded them, and yet the sky did not fall, eventually the UK lost their face of "we do not talk with terrorists", the IRA became involved  in the political process, some political prisoners were freed, and now things are not blowing up.  The UK government got up to some pretty shady things in the history of the troubles also.  Its just possible that the current problems have an element of blow-back and two sides to any argument also.  Its kind of interesting from inability to learn from history that the UK government finally admitted and will compensate victims of its past torture of kenyan resistance fighters and civilians including Obama's grandfather in kenya troubles, and here is Obama presiding over the next generation of the same picture (the powerful torturing the weak for attempting asymmetric and reactive warfare).  That still seems to me like a retrograde step, trials were heard at nuremberg about such activities in the past for good reason.

Adam

So apart from the political blather this bit seems to be like a potentially interesting idea, perhaps other people had the same idea before


ie why not as a design objective try to separate identity from coins.  So you make the coins payee and payer anonymous, and then each user has a wallet identity/pseudonym that maybe optionally disclosed to the other party, or revealed to other party or to the auditor in event of dispute.  In that way we avoid taint, and yet the privacy and anonymity of the payment system becomes more arbitrarily tunable and even negotiable between parties, or set by system default.  Taint and tracability of taint is bad because it affects fungibility (in a p2p respendable ecash system like bitcoin, random users end up holding retroactively tainted and reduced value or unspendable coins through no fault of their own, and this erodes confidence).  But a system may like to offer or aim for a specific privacy level or traceability of amounts and identities.  Those things thereby become separable.  Nice :)

Now all we have to do is find a way to make zerocoin efficient.  (And that seems to be the question of the hour - its not at all obvious how to do that).

Actually its an open question how far bitcoin direct chain transactions scale, so maybe there is some hierarchy of off-chain (or sub-chain) that evolves eg around miners, exchanges, or p2p sub-chains that offer lower value coins, that backed by the main chain but not detail validated by it.  The supposition being that if bitcoin does hit a scalability limit (fails to scale as fast as its adoption), the minimum effective transaction value amount that is economical to send due to fees will go up, a lot.  Maybe the main chain is used for inter-chain clearing and investment level bitcoin holdings.

So maybe the privacy policy types of things get decided by competing sub-chains and off-chain transactions in such a bitcoin world.  And seemingly its not obvious how to do sub-chains and off-chain transactions without trust for double-spend protection.  (Which is why things like fidelity bonds come up in this scenario).

Adam

A good way to think about the issue is that a digital currency can be either based on consensus, authority, or detection and punishment.

Authority is the easiest to understand, that's just how PayPal works. Authority-based currencies have the best scaling properties because with 1 authority, n transactions results in n work. Trust in an authority-based system is absolute at the protocol level.

Consensus is how Bitcoin works, but because everyone needs to have the full transaction history, n transactions results in n^2 work. Of course, you can cheat and reduce the number of full nodes out there, but it starts looking increasingly like an authority based currency. Trust here is again absolute, but you are only trusting a majority of participants in the consensus voting scheme.

Detection and punishment systems are a mixture of the two. You trust some local authority, but you maintain automated ways to detect that fraud has occurred, and automated ways to punish that fraud. Unfortunately in Bitcoin as it stands the best way we can punish fraud seems to be to just stop doing business; fidelity bonds make that action expensive for the fraudulent party, but they aren't perfect. With some changes to how Bitcoin scripts work we can turn a proof of fraud into a direct punishment, or even an action that triggers a refund of the funds held by the third party, but that will require a soft-fork at least and a new scripting system. How these systems scale really depends on how efficient detection is, but n*log(n) work appears to be a good rough estimate.

We do need more work on the mechanics of detection, especially with looking into the possibly of changing the scripting language so that punishment/refunds can be done directly.

At the same time, at worst the scaling approach many are advocating turns Bitcoin into an authority based system in the long run, and at best turns it into a detection and punishment system, albeit one with fairly limited punishments that themselves can cause serious problems for the system in terms of technical complexity and stability.

Here's a concrete example of how a more flexible Bitcoin scripting language would allow the creation of a system with properties between Zerocoin, and conventional chaum banking systems. Credit goes to Gregory Maxwell for the basic concept:

First you deposit your funds with the chaum bank, and receive a chuam token back.

The bank maintains a txout on the blockchain with funds >= all outstanding tokens, and with a scriptPubKey of the following form:


Now I can provide proof to the blockchain itself that I am entitled to receive the value of my token back, and I can do so without the co-operation of the bank.

Totally off-chain transactions, IE chaum-for-chaum exchanges, can be handled as well by having the bank include all outstanding tokens in a merkle tree, and signing the tip of that tree along with an ever increasing serial number:


Now I can "spend" the txout with ever increasing serial numbers. This allows multiple different users, each of whom may have a different idea of what the outstanding token set is, to converge to the last valid set of tokens. If they do so randomly that will happen in about log2(n) steps.

After the timeout the txout goes into the state of allowing people to get their funds back, and again, without the co-operation of the service any token can be turned back into Bitcoins. Of course, some of the tokens may be of too small a value to economically redeem, but in that case we're just back to the "pure-punishment" case.

I'm leaving out a lot of details of course, but in general what's nice is we get the anonymity of Zerocoin and off-chain microtransactions in one system. The trust in the central bank maintaining the ledgers is fairly minimal, and there can be as many of these banks as you want. The system can easily scale to extremely large transaction volumes without a corresponding increase of the blocksize. There may also be some clever way to remove the requirement for the bank and maintain the ledger via an alt-coin consensus system.

We could implement this with a soft-fork to Bitcoin that extends the scripting language with new opcodes and merklized abstract syntax tree support. My very rough guess is that it's a year long project to get the new scripting code written and tested, and maybe another year to deploy on mainnet.

Has this been completed?

What ticked me off is the quote from Wikipedia in the context of adam3us signature


I realized that I was wrong after adam3us clarified:





My question about a quote from Satoshi was actually a serious one, there is a lot of things I missed or don't know.

P.S. sorry for the off topic, won't post about it here any more.

The limitation I see with Chaum credentials, for off-chain transactions backed by bitcoin is that the transaction server could issue more chaum-coins than there are bitcoins, and you will never know until you find your chaum-coin is irredeemable because the bank is out of bitcoins, having redeemed them itself under a pseudonym with extra unadvertised chaum-coins it minted for the purpose.  Because they are not linkable you cant make a chaum-coin lock an on-chain bitcoin nor collectively all issued chaum-coins also cant lock a claim to the pool of on-chain backing bitcoins.  (Or more likely the bank gets away with it for a while, like an over-leveraged fiat bank with off-book liabilities until there is a run on the bank).

(And I guess its been tried, monetas OpenTransactions system implements David Wagner's blind MAC (in the form of Ben Laurie's lucre library) something similar to Chaum and I think is flexible enough to issue Chaum-alike credentials for bitcoin).

Thats because while the Chaum bank can demonstrate it is holding some bitcoins, the coins are blind and not linkable.  So you cant tell when an extra coin is used (that was not backed by bitcoin) to claim a not yet spent bitcoin, rightly belonging collectively to the set of bitcoin backed chaum-coins.


That could be interesting, but the chaum-blinding doesnt directly work as the way bitcoin consensus is to put it inside a merkle hash inside a massive hashcash stamp.  Maybe you could put it inside an RSA accumulator instead, which is a more blinding friendly algebraic construct.  However that is basically what ZeroCoin is trying to optimize.

Adam

Yup, that's one of the important details I left out for brevity.

The chaum bank can be required to maintain a signed audit log of every chaum token created and destroyed in the system; obviously value in - value out <= backing funds is a condition that must be always maintained and proven by the log. We'll call the audit log A with A=a₀...a_n and every entry in that log in signed by the chaum bank. In particular, part of the process of obtaining or redeeming a chaum token is that the bank gives you the entry in that log applicable to the transaction.

Now if you can prove a_i ∉ A, you've shown that the bank commited fraud by signing an audit log entry that it did not include in the master log. Also if you can prove a_i ∈ A and a_i±1 ∈ A, yet a_i and a_i±1 are inconsistent, you've also proven that the bank is attempting to commit fraud, perhaps by creating a token not backed by funds on the blockchain.

The bank now creates a txout with the following scriptPubKey:


This txout acts as a fidelity bond, and anyone who can prove the bank committed fraud gets to collect a reward, but only by proving to the whole world that the fraud happened. The whole world can then get their money back via the mechanisms I outlined above. Now you'll actually want to do something a bit more subtle to ensure that it is never in the banks incentive to commit fraud, then report themselves for fraud with a scriptPubKey of the following from:


For a bond of value m, the finder of the fraud collects m - n - fees, and n Bitcoins are given away to a random miner. Just make sure that m - n - fees is sufficiently low that perverse incentives do not exist.

Of course publishing this audit log and verifying that it is valid has some overhead, potentially O(n^2) roughly speaking, but because we can have an arbitrary number of these banks we keep n small and the system is scalable even without using any sophisticated cryptography. By creating an incentive to find and publish fraud, we ensure the auditing infrastructure exists and is actually done, and because it is entirely math-based the auditing can be done completely automatically (and hence cheaply) by all parties involved. This infrastructure can be something like a P2P flood-fill network that keeps participants up to date on log information, or something as simple as a central service - there are lots of options to explore. I'm sure that the act of checking these audit logs will pose some edge-cases with privacy implications, but in any case the privacy achieved is strictly better than provided by on-chain transactions.


Incidentally everything I described above is applicable to my fidelity-bonded bank concept, with the key difference being that with support in the Bitcoin scripting language the result of fraud can be that the clients of the service get their money back rather than just the bank gets shut down.

Is there a write-up of this somewhere? I need a lot more detail to understand what you are describing.


blinded chaum token = random "serial number" generated by you, encrypted with secret key known only to you, then signed with private key corresponding to well-known public key by bank?


Maintains a single txout rather than a Bitcoin address with the required amount in several transactions? Is this to sever any link between a specific txout and a redemption? How does the bank update this single txout when it issues a new token? I see nothing about this in your proposed script.


proof =  random "serial number" generated by you, directly signed with private key corresponding to well-known public key by bank through the magic of a blind signature and not already redeemed in a previous transaction?

same restrictions = new txout contains more than is necessary to cover all remaining oustanding tokens (i.e. previous amount minus what was just validly withdrawn) and requires a new not-yet-redeemed token?


tip = ???
similar conditions = ???

Its a desirable audit requirement but I think the blinding may prevent it.  Lets call the blind chaum coins c' and the normal (unblinded) chaum coins c.

(And it works because blind proto-coin p is sent to the bank p=r^es mod N, bank signs to create blind coin c'=p^d=rs^d, and user unblinds by dividing by blinding factor r: c=c'/r=rs^d/r=s^d.  So the bank sees c'=rs^d on withdrawal and c=s^d on deposit.  s is the serial number.)

The bank on withdrawal exchanging bitcoins (call those coins b) for blind coins can log (c'₁,b₁).

On deposit exchanging chaum coins for bitcoins the bank sees c and b, so it can log (c₁,b_R) for some random bitcoin b_R.

Finally on chaum->chaum off-chain transaction the bank swaps a non blind coin for a fresh blind coin, so logs (c₁,c'₂).

The problem is if the bank logs two withdrawals (c'₁,b₁),(c'₂,b₂) and then logs deposit
(c_fake,b_R) the auditor cant correlate c_fake with either c'₁ nor c'₂ because of the blinding, even user 1 and user 2 who know their respective blind factors can't tell that it isnt the other user doing the deposit without breaking their privacy.  Unless they somehow all club together to do a ZKP to prove that a withdrawl is none of their coins which might be possible, somehow prove they know the blinding factors in one of the withdrawals that matches the deposit.  However that sounds a lot like zerocoin set membership level of efficiency proofs.  Maybe could still be interesting if it is off-chain.


Is that described on the bitcoin wiki under fidelity bonds?

Adam

Embarassing, I should actually read my old notes before posting... Yeah we saw that problem months ago and figured the only good solution was to accept that whatever funds are tied up as chaum tokens directly aren't auditable to the same level as non-blinded funds. However once someone spends a chaum token in exchange for non-blinded credit, you are back into solid auditing again, so it basically becomes a trade-off between anonymity set size and the window for fraud. Of course, that problem is applicable only to chaum tokens, so as a micro-transactions system without strict anonymity the idea still works very nicely and is probably about the most minimal level of trust possible, especially in that you can get your money back even if the service simply vanishes.

We hadn't heard about zerocoin at that point. I agree that the idea is far more feasible as an off-chain system; the trick would be to determine what constitutes fraud, how to prove it, and how to turn those proofs into something short enough that a reasonably short scriptPubKey could evaluate it. I guess essentially fraud would be allowing a chaum token set change that is invalid, but I don't know enough about the applicable math to comment there. If you can construct systems where proving fraud is reasonably efficient then the idea is feasible. (detecting fraud and using the system as a whole can still be inefficient)



It's mentioned, but not really described. Basically though the idea is really similar to what I wrote above, except that without scripting support the only action that can be taken when fraud is published is to stop using the bank. The trick is that provided the fidelity bond is worth something, you can know that the bank is in a position where committing fraud would be a net loss for them. Part of that involves being able to sell those bonds and transfer them to other parties - IE solving the retirement problem.

I wonder if there is a way to use zerocoin off-chain to implement the auditable chaum-like thing, presumably zerocoin is the closest protocol.  Zerocoins are so far not transferable - you buy them with bitcoins and sell them for bitcoins.  But you could transfer a zerocoin - just sign the new accumulation with the old coin and put the old coins serial number in the double spent list.

Recalling when you accumulate you have to spend a bitcoin (sign the accumulated coin c), and that authorizes you (in the view of all full bitcoin clients) to add c to the accumulator:

sig(b,c) and A' = A^c

signature using the bitcoin key b from bitcoin b.

when you convert it back to bitcoin:

ZKSoK[R]{(w,c,r): A==w^c mod N and c==g^sh^r mod p}

w is witness (accumulator excluding c), c is the coin, s is serial number, r is random never disclose, R is the data the signature is over.  R in the case of conversion to bitcoin is a bitcoin b, and the new owners bitcoin address.

If we want to transfer zerocoin to zerocoin without going via bitcoins we could do that too.

Just set R to c the new accumulated value of the new owner, and update the set of spent serial numbers with s which is disclosed as part of the ZKP.  Now you have a replacement freshly unlinkable zerocoin.

Now why would you want to convert a zerocoin to a bitcoin?  Its purely an efficiency argument - zerocoins are more work to validate and bigger.

You could directly mine zerocoins also.  Just allow mining to a zerocoin accumulation directly.  Ie the winning miner in each block is allowed to include 25 coins in the accumulator.  

So we could build a zerocoin alt-coin that doesnt directly use bitcoins at all with zc mining, and zc-zc transfer, and its own zc serial number double-spend validation in place of bitcoins linkable double-spend validation.  Maybe its merge-mined  (though that creates a strange conflict where miners get both 25 zercoins and 25 bitcoins for the mining price of 25 coins) or just track bitcoins difficulty, and bitcoin mine with intentionally unspendable mine-to addresses, that are valid  zerocoin addresses.  I think a "fair" merged mining aiming for price parity would be done by the miner having to choose zc or btc at mine time, and zc chain considering btc unspendable and bitcoin considering zc unspendable.

Maybe one could trade zerocoins for bitcoins.  Probably zerocoins would sell above par because they are taint free, in the same way that fresh mined coins reportedly have sold above par.

If bitcoin main choses not to integrate zerocoin - and indications so far is it wont for compute and storage efficiency reasons, and perhaps other reasons, then maybe this would be something interesting for a new altcoin.

I think people have proposed methods to trade altcoins for bitcoins without an exchange through some kind of simultaneous trade protocol?

edit: seems to be something wrong with this - dont miners on bitcoin networks have to be aware of validation logic of zerocoin alt-coin network, otherwise they will accept merge-mine of invalid eg forged zerocoins

edit2: maybe we can say that a mergemine does not count as a validation of the network for the respective network unless there is serialization in the coinbase indicating that the network is validated.  In that way you could have zerocoin mined and zerocoin validated, zero mined and bitcoin validated (strange but possible), zerocoin mined and both zero and bit coin validated, and also the same for bitcoin mined and zerocoin validated (strange but possible), bitcoin mined and bitcoin validated (normal bitcoin ignoring zerocoin) and bitcoin mined and bitcoin and zerocoin validated.  Then the validation events on zerocoin network might not be as frequent.  Maybe miners will tend to validate both networks as then they can claim fees on both networks, even if the protocol prevents direct merged mining on both networks (one or the other mined, and whatever chains validated as indicated by coinbase serialization).

Adam

We'll be publicly releasing libzerocoin (alpha version) on July 4th. We're looking for testers & integrators!
https://twitter.com/ZerocoinProject/status/352136561397215232

Who's we? ... good news btw.

I'm not their spokesperson but I guess it's the university researchers (prof & his students) working on their papers and this is the implementation. I wonder if they heard of testnet and bothered to add a flag to run on testnet before potentially destroying real coins

My guess is that this library isn't in any way made for Bitcoin, but is simply a group of functions that handle the cryptographic aspects of zerocoin. Ie. it abstracts away the underlying cryptography into functions that can be used by programs that wish to use this functionality. It would be someone else's job to integrate this into Bitcoin, if so desired (which, I gather, it is not). But that's just my guess. If this weren't the case, I think they would announce a fork of Bitcoin-Qt and not something called "libzerocoin". But we shall see.

The whole system was designed as an extension of Bitcoin, and there was a proof of concept implementation when they published their paper a while ago.

So, is the only thing that will decide whether this is used or not is whether miners will be willing to include the larger transactions?

We need a hard fork for this to work. Coins are changing owner based on some added cryptography.

gmaxwell said it could be a soft fork: https://bitcointalk.org/index.php?topic=216982.0

I don't really understand the math behind zerocoin. However, if the "added cryptography" is more restrictive than current rules, that would be a soft fork

I don't understand the math either.

But as far as I can see, if I transfer X BTC from address Y and convert them to a zerocoin, which I then transfer to address Z, then clients need to know how X BTC went from address Y to address Z, and that involves the zerocoin code.

But at the same time I value gmaxwell's opinion greatly. I would be interested in seeing an explanation from him on exactly how this can be achieved with a soft fork.

Can the Zerocoin stuff be done in Bitcoin script?

No, it cannot be done in script. See my answer on the other thread for the soft vs hard fork issue. The brief answer is that in a soft fork you arrange things such that to old nodes, all ZeroCoin transactions always appear to be valid. It means those nodes can accept blocks that are incorrect according to the ZeroCoin rules, and the assumption is that as long as most hash power is upgraded, miners will eventually orphan the invalid blocks and old nodes will re-org onto the right chain. However those nodes might believe the bogus transactions for some arbitrary amount of time.

ZeroCoin is not mergable into Bitcoin as is. But if it was, you're right, it should be a hard fork. There aren't any compelling reasons to use soft forks, IMHO. It is at best controversial.

Lol.

For the newbies reading this, basically Mike is saying there isn't any compelling reason for backwards compatibility, and every change should require that every single Bitcoin node upgrade all at once even when doing so in a backwards compatible way is trivial. Needless to say, it's not an opinion shared by many... For reference, here's Gavin's "Bitcoin Rule Update Process" guidelines: https://gist.github.com/gavinandresen/2355445 which were quite successfully used to implement BIP 34 (https://en.bitcoin.it/wiki/BIP_0034)

Rule changes are, by definition, not "backwards compatible". That is the whole point of Bitcoin. You are SUPPOSED to get hard forked off if the rules change and the fact that blocks stop being processed at that point is deliberate.

Yes, if you were to introduce something like ZeroCoin, ordinary users would expect it to be a hard fork. Soft forks are a nasty hack that violates peoples expectations of how their nodes will behave in the face of rule changes.

Rule changes could be backwards compatible, e.g. allowing homosexual marriage would not make any existing or future heterosexual marriage illegal. The opposite is true for bitcoin: tightening rules would not make existing clients obsolete

The ability to soft-fork is one of the most visionary design in bitcoin

I saw this: https://github.com/Zerocoin/libzerocoin

It has begun!

Wow! Looks like the Bitcoin community never stops!

This is so cool!

BTW: Where can i donate to support the project?

The point of a soft fork is that the rules don't tighten - from the perspective of old clients, anyone can spend any zerocoin and you will happily accept blocks that contain bogus spends written by unauthorized users. This reduces your node to SPV level security (you blindly trust whichever chain the majority of mining is done on). Silently downgrading peoples security level is not only a nasty hack, it's untrustworthy behaviour which is why I objected to it for P2SH.

Bitcoin has never been designed to "soft fork". That's something other people came up with later. Everything in Bitcoins design is intended to trigger hard forks when the protocol changes.

Hard forks are not impossible or the end of the world, they just require co-ordination and communication. It is the right way to do things and I will continue to strongly object to "upgrades" that convert full nodes into SPV nodes.

No soft-fork is possible without majority of miners agree. If they decide to tighten the rules, all users have no choice but to follow. This is a known feature (or vulnerability) of bitcoin from day one. Sometimes it is called a "soft-fork", while sometimes it is called a "51% attack". Anyway, it's the users' responsibility to keep their client up-to-date to adopt the tightened rules.

If Satoshi had never thought of possibility of soft-fork, I couldn't see why he included so many useless OP_NOP codes in the script.

No, that's not true at all. The whole point of running a Bitcoin full node is that you do NOT blindly follow any rule changes miners agree on. That's fundamental. If you do blindly follow them then you're using simplified payment verification.

If the majority of miners decide to restrict block size to 100kbytes, what non-mining full node could do? They could either follow, or join a shorter fork with bigger block size (i.e. hardfork ). Non-mining nodes don't really have much choice

Anyway other than the question of whether soft forks make sense or not: what about making an all zerocoin based alt-coin (no bitcoins, nothing but zerocoins), that is either-or mined with bitcoin.  Then people can trade in and out of zerocoins by buying or selling them for bitcoin with an atomic transaction, probably p2p without some trusted exchange like mtgox.

Either-or mined (as distinct from merge-mined) I mean that each mined coin set is either a set of 25 bitcoins or a set of 25 zerocoins.  If its a zerocoin set its not a valid bitcoin set, and if its a bitcoin its not a valid zerocoin.  I'm not sure the zerocoins or bitcoins have to do much with mining events for the other network other than check they have the expected number of bits as they wont automatically know how to validate the other network.  Some miners may choose to validate both networks, but thats a choice for them.

In that way people can experiment with zerocoin, without bloating the block chain, complicating bitcoin, and without slowing validation on the bitcoin network.  And the two coins should have approximately the same cost (and maybe therefore value, though the price would be subject to demand/supply and any taint discount for bitcoins; zerocoins are taint free, or perfectly blended taint at least).

Adam

Yeah, I agree with Adam, an alt coin with an integrated ZeroCoin would be a very interesting thing to play with. The chain-trade algorithm can be integrated to make trading bitcoins for altcoins easy and decentralised.

While true, because miners control transaction selection, there are a great many rule changes that miners cannot make, no matter how much hash power they have.

Sure, I am talking rules tightening only. Something like increasing block size must be a hardfork

I posted a zerocoin based alt-coin strategy as well if you're interested:

+1

I really like Adam's very creative idea earlier in this thread to have a pure-zerocoin system:

https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768

The zerocoin paper proposed a hybrid bitcoin-zerocoin system. Bitcoins would be temporarily exchanged for zerocoins, and then exchanged back. Adam's idea was that zerocoins would be exchanged directly for zerocoins. Zerocoins could be mined directly, too. All this is a simple modification of the zerocoin protocol. In fact, it would be simpler in terms of code size, because you wouldn't have to support bitcoin transactions. No scripting language, no bitcoin validation rules. Just pure zerocoin spend transactions.

This would also free us from the forced assumption of bitcoin-zerocoin parity. The heavy resource requirements of zerocoin might naturally break that parity. (Admittedly, zerocoin would first be implemented as an extension to an alt, so the value in terms of bitcoins would float. But the simplification is still a win.)

There are various proposals to do P2P exchanges between altcoin chains. I don't know what the status is as far as Bitcoin support in the bitcoin-qt client. You'd have to have a new client to do the P2P protocol. But even if we had to rely on an exchange, it would be an interesting experiment.

The last problem for a zerocoin implementation is the generation of an RSA modulus for which no one knows the factorization. This is hard, and deserves more analysis.

You are welcome to vote for Zerocoin as Bitcoin Project of the Quarter:
https://bitcointalk.org/index.php?topic=251087.0

If someone finds out the factorization, what are the implications? All the anonymous transactions become public?

No, but they can use the key to create fake zerocoins. (basically they can fake the proof that they added a zerocoin to the accumulator)

Maybe it could be implemented on the Bitcoin testnet at some point? (with the risk of breaking it as well)

Though as you said, finding a zero-cost solution will not be Zerocoin and Zerocoin as I see it may demand 10 times the resources of the current running implementation of Bitcoin.

What do you others think? Should Zerocoin be implemented in Bitcoin or should it be tried first on a new or existing cryptocurrency? There's a libzerocoin at github. The most recent commit was at 2013-07-12 02:04 titled

I think a totally new alt coin should be created for zerocoin because that is lowest risk and barrier is lowest.

Except there is risk, if this alt coin takes off and zerocoin is seen as an attractive alternative it could supersede Bitcoin.

I understand that the Bitcoin developers could add zerocoin, but it would need to be tested and all the miners and nodes would have to agree, all this whilst the new alt starts to erode Bitcoin market share[1]. The worst case scenario is many Bitcoin whales see the writing on the wall (Bitcoins developers arguing, not reacting fast enough) and exchange significant parts of their holdings over to the new coin. If this happens we might witness a runaway effect that moves most commerce over to the new coin and anyone left with Bitcoin being a loud whining bagholder.

I think testnet Bitcoins should be used as a testbed, to limit the possibility of a competitor quickly rising.

Many of you will laugh me off as paranoid, I approach these issues as a "think of the worst case" situation and prepare for it.

[1] If you think this is stupid please consider how Litecoin has an estimated 5-10% of Bitcoin hashpower whilst offering nothing in terms of real advantages, A real competitor will also attract vast amounts of people who were not original early adopters and they will fight forever tooth and nail to make their investment worth more. This is going to be a can of worms. I can see a monster being born to destroy the creator.

I think we will waste a lot of time and resources by assuming the worst case and preparing for that. It does not seem like a rational strategy to me.

The rational strategy would be to weigh risks and benefits, and adopt the solution that best balances these two aspects.

In the case of Zerocoin we have both a lot of added risk (the protocol hasn't actually been deployed yet), and it increases the hardware requirements (CPU power, storage space, bandwidth) of running a full node.

Given that the benefit is, at best (ie. in case there are no vulnerabilities), full anonymization of all transactions, and given that this can already be achieved selectively by individuals who require this feature, I think Zerocoin should be implemented as a separate cryptocurrency, and tested out completely separate from the Bitcoin protocol.

I think a lot of people quickly forget just how unsafe Bitcoin was regarded as just two or three years ago. This would start all over again with a modification of the core protocol, and if you worry about a declining price of bitcoins, I believe modifying the existing core Bitcoin protocol would do much more harm than a separate Zerocoin taking off. At the bare minimum it will take as long as Bitcoin has existed for people to trust that protocol, and probably longer because introduces more complexity into the core protocol.

In other words, I don't think we are in a hurry. Zerocoin, as a separate cryptocurrency, will take a long time to gain confidence from users.

If you are afraid it will supercede Bitcoin then buy some "Zerocoins" for your bitcoins. It's as simple as that. Cryptocurrency-to-cryptocurrency exchanges are extremely efficient, and you could hedge your position as you see fit, instead of forcing every Bitcoin user to adapt to your worst case scenario.

If this separate Zerocoin becomes more popular than Bitcoin, I'd be very happy! It would mean that it has greater value than Bitcoin to the people using it. Bitcoin is already amazing, improving it can only be positive. If you worry you will lose out financially on this, then, again, buy some "Zerocoins" for your Bitcoins.

Thanks for your response, very well reasoned and after reading what you have to say I do agree.

I didn't think about the possible downsides to Bitcoin if it was forced onto all the users and then if it was found to be insecure the loss of confidence would indeed be devastating.

Cheers runeks.

Thank you for a well balanced discussion. I would like too emphasize the part inn my argument concerning barrier. It could potentially take a long time t convince bitcoin community to accept zerocoinn development, hence the effort involved in creating a new alt zerocoin would be lower (no one at all to convince, no concent needed and so forth and so on). If zerocoin is a success and worthwhile integrating in bitcoin the discussion about doing so could then be had and at that time with more certainty about risk and benefit. My take on zerocoin is that IF third party trust could be somehow removed then that would be a major improvement. If not, research and more knowledge is good anyways.

Launch a Zerocoin testnet. A Zerocoin testnet would say "Here's how it works in practice" with 0 price.

...
or do you maybe trade Bitcoin testnet coins already? ;D

...that's why I assume that Zerocoin testnet coins would never be traded but just show if it is stable or how much processing power it requires.(is it hackable? Maybe it is hackable? Great introducing new security to Bitcoin, NO THANK YOU! ...and then making us a point of ridicule among the worldwide community)

If we assume that enabling Zerocoin as an extension to Bitcoin causes a 200% slowdown. So that instead of taking 300 seconds to validate 80000 blocks, it now takes 900 seconds to validate them, on some specific hardware setup, then it would again be a "no, thanks".

The reason there is not even a testnet of Zerocoin as something to compare to I would say that Zerocoin is today 2013 in September 0% likely to get implemented in Bitcoin(not even close to the Bitcoin testnet), even my speculation says it is 0% likely.

People have, and we've had to reset the testnet multiple times and make some minor changes to undermine the security of it.

But even if you do this, someone will just copy the code into FooNinjaRealUltimateCoin... so you can't get what you want there.

This has resulted in several occasions of altcoins cropping up 'competing' with Bitcoin by copying code from the Bitcoin core team which was just not mature enough yet to deploy in Bitcoin... greenfields are much easier and faster to deploy into. It's like the Microsoft "Embrace, Extend, Extinguish" business model but supercharged since you can just extend by copying code written by your competition!

But hey, if something based on Bitcoin that has ZC is preferred over Bitcoin by the public— then perhaps thats what should happen.  The costs of ZC, especially without network-pseudo-interactive cut-and-choose to make the proofs smaller, make this seem unlikely to me.  Certainly introducing non-consensus features via an alternative coin is improved in terms of obtaining consent then just merging it in an existing coin.

https://anoncoin.net/ mentions as of August 30, 2013 that they will begin implementing Zerocoin.
...if it works.

I guess it will make it first into some Anoncoin testnet, maybe a testnet specifically for zero-knowledge proofs.(learnt about this from the Zerocoin subreddit)

https://github.com/CryptoManiac/novacoin/wiki/Zerocoin-transactions

In progress too.

I thought coinjoin was a better way to do this? As a natural mixer I really like the idea of coinjoin.

uh wtf is with that novacoin page?  Did the author of that look at how script works at all?

There shouldn't be additional script pushes for this. This should use the existing push opcodes and add new CHECKSIG operators. :-/

Yep. :)

There is no plan to start anything like this in the main net, of course. That's ugly hack for the testnet, and it will be replaced with an appropriate implementation later.

https://twitter.com/matthew_d_green/status/401797786347114496

https://twitter.com/matthew_d_green/status/401798811070107648


Is a 98% reduction in proof size enough to overcome any existing valid reasons to not merge ZeroCoin functionality?

/\NVC= this is great !!  8)
 *->keep up the good work!

https://www.cryptsy.com/markets/view/13

I think so, Matthew Green mentioned that he was planning to implement Zerocoin into its own cryptocurrency. This seems like a reasonable idea me, it lets us test Zerocoin, and if it works well, we can merge it into Bitcoin (without the risk of damaging Bitcoin if something goes wrong).

btw see also "bitcoin staging" aka betaCoin. 

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02944.html

Its a way to one-way peg an alt-coin to bitcoin, so there is no native mining, the way you create coins in the alt-coin is my moving bitcoins into it.  And the way to trade them back to bitcoin is to swap them with someone who would otherwise move one.  If a security problem develops in the betaCoin, people stop swapping betaCoin at par for bitcoin, or market freezes until the issue is fixed.  This is the minimum necessary feature to firewall bitcoin from betaCoin security issues while allowing bitcoins to move between betacoin and bitcoin in the normal case.

This is how I would go about doing an alt (otherwise the usual me-too coin is contingent on the hope of getting in early, or early mining and selling to next stage speculators before the pyramid collapses when it becomes obvious it has no chance of competing with bitcoin for acceptance.  As this coins have no acceptance, they have no transactional value, their own value is speculative, which I think must implode at some point.)  Also even in the hypothetical that a given coin did overtake bitcoin it could be a dangerous outcome as then what happens to the value of bitcoins?  Such an untidy unravelling of bitcoin value would hurt the overall concept of digital scarcity.  Say it was litecoin.  Then if litecoin got to like 90% to bitcoins 10% BTC/LTC exchange would fall.  But then people will be looking nervously at the next runner up, and hedging in the main runner ups.  This is a net disservice to digital scarcity.  Digital scarcity is a new virtual asset class, and I think is the future of money and financial networks.  So we dont want to weaken the concept with me-too alts, even relatively well thought out ones because they define a new digital scarcity race.  I think there should only be one credible digital scarcity race or we may have a problem.  Digital scarcity becomes digital tulip, then who wants to invest in the next one.

betaCoin is also a way to do an alt that preserves the 21 million coin cap.  Fees would be paid in betacoins (or bitcoins).  Miners would mine both networks for profit maximization reasons.

Adam

The betaCoin model is interesting, but I'd just make one import remark though: in this model, there's no financial incentive for people to migrate from bitcoin stable to bitcoin beta, since stable coins will always be more valuable than beta coins. This means that, from a monetary point of view, this beta risks being just a testnet++. Not many people will transfer their coins into it (it is not a reasonable investment strategy), and without much aggregated value, would it really have enough manpower behind it? If Gavin and Garzik are being fully employed to work on Bitcoin right now, it's precisely because bitcoins are valuable to lots of people. If there was a technical way to ensure people can get their beta coins converted back into stable coins at the same rate (i.e., pegging), then things could be different. But I don't see how could that be possible.

Anyways, I came here for another reason. I'm really interested in Zerocoin and I'd like to understand how it works. I can understand the basics of public key cryptography, and blind signature - although the math behind these algorithms are things I simply "trust to be true". :) But Zerocoin... damn, is that complicated! I tried reading the paper once it got out, and I couldn't understand a thing.

Is there an easier explanation somewhere, that could help technical people without a background in cryptography research to grasp the concept?

Thanks

well rather than the get rich quick, get in early motivation for the me-too alts, the idea is that you get into it because you want the features it provides.  eg if zerocoin used the model.

Now thats not as strong an incentive as make-money-fast pyramid speculation on frankly long-term hopeless me-too alts.  But if the idea is that it is going to become the new bitcoin in say 1 year, once the features are well validated.  Then it would help reduce concern of being stuck.

The reverse swap depends on demand.  If people dont care about the new features they wont use it.

I would think something like maaku & jtimon's freimarkets would be a good candidate for doing this way.  Freimarket is not related to frecoin - its a native coloring and smart contract proposal.


technically it could be done, (bitcoin could accept coin moving in the other direction) however it imports risk into bitcoin main as a security defect in betacoin that allowed theft or forgery of coins, could then be transferred into bitcoin.

Once the beta is over, the remaining coins would be bulk oved in a hard fork and beta wold become main, and a new beta started.  eg on a yearly cycle.  like fedora and redhat enterprise linux or linux kernel stable and latest etc.


see earlier in tis thread:

https://bitcointalk.org/index.php?topic=175156.msg2378622#msg2378622

and another few posts after it where I tried to explain it a bit.

Adam

I agree with adam3us, a betaCoin implementation of Zerocoin would be excellent. It would help Bitcoin, the preservation of the credibility of digital scarcity - particularly of Bitcoin-based cryptocurrency - and the adoption rate of Zerocoin by making its acquisition as easy as that of bitcoin (which can be purchased at a far greater number of places than an altcoin can ever hope to be in its first couple of years).

A person who wants to try Zerocoin would simply download the client, which stores both bitcoin and zerocoin, send some bitcoin to a bitcoin address linked to that client, enter how many bitcoins they want to convert to zerocoins, and then click a button that says 'convert bitcoin to X zerocoins', with X being a multiple of whatever conversion rate is decided between the two.

See for further discussion on the betaCoin concept:

https://bitcointalk.org/index.php?topic=248865.0


The pricing of betaCoins would behave similarly to that of bonds, which are capped to the sum of the principal at maturation date and all future interest payments. There is still a market for bonds, and opportunity for their appreciation, despite their value being capped relative to the currency of payment, because the present value of their future payments fluctuates according to the perceived risk of the bond defaulting on its future payments, and the borrowing cost of money.

Please don't replicate the same silly attacks people tend to use to discredit Bitcoin. The financial incentive behind the technology is what brings lots of the manpower, business and infrastructure it has today. Not to acknowledge that is to be willingly blind.


If the defect was only on the betacoin, then the damages would be restrained to those who willingly converted stable coins into beta coins. That's not an issue to me. When you do so, you accept the risks.

Hey, this very feature (allowing the redemption of arbitrary betaCoins built on top of it) could actually be the among the firsts betaCoins. ;) If it works well, it will set up a great platform for experimentation!


Thank you. I've just watched this video (http://research.microsoft.com/apps/video/dl.aspx?id=192058) following a recommendation of jron (http://www.reddit.com/user/jron), and what I could get from it was the following (http://www.reddit.com/r/Bitcoin/comments/1qtevg/zerocoin_reduces_proof_size_by_98_plans_to/cdgfhbk):


Am I getting closer? ???
Your explanations kind of hinted me in that direction too.

Thank you!

That's a great idea from a purely technical perspective.

Realize that when money is at stake other factors will come into play.

Zerocoin is a highly desired feature. As soon as they release this coin, it's going to attract investment and it's exchange rate will rise quickly. People are going to put a considerable amount of money into Zerocoin.

When Bitcoin implements these features, it will threaten the value of their investment. Do you think they are going let that happen calmly? They will do everything they can to obstruct the change. They'll come over here and spread FUD, start arguments, and in general make life difficult for any developer seeking to push the change.

This happens already - If you go back to the beginning of this year and read through flamewars regarding scalability and the blocksize and pay attention to the people most fervently opposed to large transaction rates, with the most ridiculous and economically absurd arguments, and then check their posting history you'll find that in almost all cases they were heavily involved with altcoins.

It sounds like ZeroCoin v2 eliminates one major criticism, that of bloat.

But engineering hurdles remain:

• 1. Requires a hard fork
• 2. Any requirement that all transactions participate in mixing is a non-starter.  Some payment schemes bootstrap trust by intentionally being non-private, showing their bitcoin holdings and bitcoin payments with provable digital signatures.

Any forced 100% privacy scheme that prevented opt-in auditing would make life difficult for some existing users, who place value in the transparency of the system.

I would rather see automatic mixing and privacy built into every client.

I've probably thought about this issue more than almost anyone with my work on fidelity bonded banking, and even ZeroCoin can be made fully transparent if you choose too. The key thing is that a: zerocoin has a public list of all spent coins, which lets you know when a coin was spent, and b: it's still possible to prove you were the one that spent a coin. Auditing in that scenario comes down to you publishing proofs of what coins you have spent in a provable public manner, and transparency is achieved by the fact that in a well-designed system you can't get away with lying about your transactions. You can fail to publish your accounting logs, an act that is of course very suspicious, but that's actually no different from the scenario with pervasive coin mixing: either way where the money went is unknown.

When it comes to receiving money, no amount of auditing can prevent you from taking money in behind the scenes, but there is no way to do that and also hide the fact that you are doing that from your sender. In this case the solution is actually identical to the non-zerocoin solution: publish in advance what addresses you accept payment on, and anyone can scan the blockchain for payments to those addresses.


Agree from an engineering point of view; ZeroCoin's requirement for a hard-fork and many lines of new code using complex crypto is a risk Bitcoin shouldn't take. Coin mixing done well has very close to as good privacy, and can be easily fixed if it doesn't work.

I guess we have to see it first.  I hope they are going to publish the crypto before the alt, presumably because the zerocoin v1 paper came out long before the library.


I think fungibility guarantee via coin anonymity is the right thing to do, as the strongest form of fungibility is cryptographically enforced fungibility.   

But I think user privacy is orthogonal to coin fungibility.  I can prove my identity while sending an anonymous fungible coin or not as I choose, if the coin is cryptographically fungible I have a choice.  As is with bitcoin I have limited choice because the coin leaks linkages.

Usually if you have anonymity as a building block users can opt to disclose and prove because the anonymity will also have keys and the user can publish their keys.  So I think it likely that opt-in public association of an identity with specific coins, or maybe with unlinkable but validatable amount of coins would be technically available, and I can see its a useful feature, so should be made an option for users.  (Eg to prove they have the bitcoins they claim to be holding for users, or disclose the amount of donations received).

About privacy in my view bitcoin is a bit too open which I think is not so much by design, but because its difficult to have privacy and the auditability SPV operation needs, because miners need to validate, and to validate they need to see amounts and transfer histories.   (Hence the interest in zerocoin and zerocoin2.)  Without needing to support SPV clients one could do committed-tx and it would be a step forward.

I think Ideally transacting parties should be able to choose the level of privacy from each other and from the public.  eg pseudonymous to each other but private to the public.  Or identified seller (because its a regulated business) and identified business (because the user need to validate the reputation of the seller), but private from the public.  In event of need to reveal more detail to selected other parties, or to the public to prove good faith, they should also be able to do that eg by publishing some keys.

In this way policing can be done by asking for information from transacting parties.  And demonstrating openness (eg for donations, charities, public companies) can be done by publishing keys.  And financial auditing can be done by a charity or company giving their accountant or auditor keys to view their transactions (but not necessarily the sender identity).

There are also privacy preserving forms of auditing.  Eg homomorphic values can still allow auditing that values add up by anyone and yet hide amounts and/or payer psueodnym is unknown (close to single use addresses but slightly stronger privacy).

So I think if we can get a cryptographic private, efficient, distributed coin with conservative security for the coin anonymity/fungibility layer then we are golden.  We can engineer/architect the selective disclosure, selective identity and different privacy concepts to dove tail with transacting party wishes.  I would say bitcoin should not make any global rule about maximum allowed privacy, because rules are different in different countries.  Rather payments should be private between the transacting parties, and it is up to the transacting parties to keep records and answer requests for information disclosure, and to provide identity to regulated businesses in their respective jurisdictions,

But its hard to do get the efficient, distributed and private ecash, thats so far proving to be another triangle thing like pick 2: efficient, distributed, private. 

So lets have a look at what we have:

- bitcoin (efficient, distributed, but taintable privacy)
- chaum or brands ecash are (efficient, cryptographic privacy, but centralized)
- coinjoin (efficient, distributed, smudged taint privacy)
- opentransactions (efficient, cryptographic private, limited redundancy)
- committed-tx (efficient, private except parties see payment history, decentralized but no SPV)
- zerocoin v1 (private, decentralized, but inefficient)
- holygrail (efficient, distributed, cryptographic privacy)

we have to see how zerocoin v2 stacks up.  Another risk point can be bleeding edge crypto that hasnt seen 10yrs of review.  Things with security proofs have been broken before.  Hardness assumptions for new things sometimes erode or slip.

Adam

Yes thats pretty much it.  Technically the coin is c=g^s*h^r and c is seen by everyone when it is added to the accumulator (though s and r are not seen by anyone).  But when it is spent s the coin serial number becomes disclosed and is stored in the doble spend db, c is hidden because of the ZKP and r is still not revealed).

Adam

You know that is a good idea, practical, can be done now, no experimental crypto risk.  Greatly reduces fungibility risks and might buy a few years.  Lets do it!

Zerocoin or equivalent can catchup when it does.

Adam

plugged in with listen mode.

The answer to what happens if 0-Coin takes off as an independent altchain is quite simple. People will invest their money in it, in order to profit from the appreciation against Bitcoin. Would that lead to a collapse of Bitcoin's value? I dont think it would in the short-medium term as like you have rightly stated many risks are associated with a new protocol such as Zerocoin. Some more risk prone investors will put some percentage of their holdings into this new currency, while others will stick with their proven and so far secure Bitoin investments. As the risks over time fade away and Zerocoin's advantages outweigh it's risks over the Bitcoin alternative we could see Zerocoin emerging as the more valuable and/or more used alternative of the two. In any way it will be a gradual process where the market balances the value transfer, processing all available information to agree on a price.

Concerning "digital scarcity": If I understand your concept of digital scarcity in this context correctly, you are afraid that the value of all finite Bitcoins+Namecoins+Litecoins+etc. will be eroded away by every new altcoin that springs up. Well, I cant see how this is not already happening and how an independant Zerocoin altchain would change that development. I think I can console your mind because not every new altchain with its added monetary base has the same effect. When a new run off the mill alt chain comes around people are reluctant to convert their assests into that coin, thus keeping the newest addition to that percived "digital scarcity" almost meaningless. The best example is Ripple with their 100 Billion XRP premined was added to that pool of digital currency units that make up the total supply of the digital scarcity. Did the advent of Ripple devalue all Bitcoins in existance instantly?

TLDR:

I think one should not worry about a sudden devaluation of Bitcoin because a new competitor comes around the corner. This market mechanic of investing your money into promising projects can be a valuable incentive for development of innovation and improvement of new ideas in the crypto zoo. And like someone else said: If you are afraid of devaluation of your Bitcoin stash, just put some into the new alt and you are good :)

Are there any infos out yet regarding the initial distribution of Zerocoins? Will they be mined or created from destroyed Bitcoins o else?

Are there any plans to keep the new chain exclusively experimental, like a Testnet or are they intended to be full on usable from the beginning?

Will the new altchain be as decentralized as Bitcoin or semi-or completely centralized?

I would not be surprised if it was released as a testnet.

I think the thing to do would be to define an exponentially declining incentive for early adoption into the inflation schedule. For instance, first 100k coins moved each get 1 bonus betacoin. Next 100k get 0.5 bonus, etc. Similar to how bitcoin halving works, except it's coin-based, not time-based. But ideally, you'd do it in a continuous way, rather than have steep halvings. Something like N(c) = 1 + exp(-c * ln(2) / 100000), where N(c) is the number of betacoins that the c'th bitcoin destroyed results in.

XCP did this : during the burn period, the later you burned, the less XCP you received per BTC.

Zerocoin will challenge Litecoin if it has fast confirmations.

Are there any actual examples of double-spends happening to someone who accepts 0-confirmation transactions in the wild? I've always attributed Litecoin's success to being the first Scrypt coin with a fair launch, consistent rules, and good community support.

what's going on about zerocoin?

i think still under developement
good news coming probably
If you want innovation just see: Emunie( forum.emunie.com and for beta test the EMU go to beta.emunie.com) and Ethereum  ;D

FYI there's a newer ZeroCash talk by Eli Ben-Sasson at:
https://www.youtube.com/watch?v=l7LSSE0bRRo
Note: I personally neither approve nor disapprove of anything said there.

The Etherum forum has a huge head start and the people there seem to have high engagement.

from what I've read from the things that comes out of traditional academia on the topic of bitcoin is absolutely worthless. there is something inherently wrong with this kind of reasoning, which seems to be obsessed with adding complexity to systems, instead of designing robust and simple systems. while studying the underlying concepts might be interesting, I'm pretty sure the effort is much better spend elsewhere. after all, code of trust protocols has to be audited, and if only 5 people understand the math, nobody is going to accept it.

I'm really very curious to see if these ideas could lead to integration of the zerocash project code down the road into bitcoin itself.  
I noticed the following remarks:


And this:

But there is no question at this point that the bitcoin development process needs to work out an anonymity solution.  From my perspective, I don't think that it has to require that the users actually utilize it, in other words, why not go down the path of making it an option (supported in the protocol, not imposed, but showing up in Core as a transaction option that the user can select to apply to any particular transaction, or none at all).  Conceptually at least, this has been the approach of blockchain.info, which with its CoinJoin (SharedCoin) implementation, leaves it up to the user as to whether to use the CoinJoin process (by being able to select 'SharedCoin' as a transaction type, or not).  While this is a good privacy feature, it's been pointed out (in Coindesk and elsewhere) that SharedCoin users can be readily identified.  (Not to mention, it's a web wallet...)
My point in this little ramble-on is that I see reason in jgarzik's assertion that it would likely be best to not impose it universally.  In other words, if a user wants to participate in utilizing the Zerocash feature (assuming that this would be incorporated into and supported in the bitcoin protocol itself) then that should be an option that would be displayed in Bitcoin Core wallet.  Zerocash is a significantly different proposal than SharedCoin, but conceptually, the idea of having anonymous transactions as an option is appealing for a number of reasons.  For example, the concepts suggested in my project [[ http://abis.io ]] favor the idea of a 'giving system' being incorporated into decentralized virtual currency wallets, but every aspect of this would be under the control of the user and could be changed at any time, making it completely voluntary and allowing for the maximum choice possible.  [In addition, one of the possibilities that I envision from the eventual implementation of http://abis.io ~ for which I am reworking / working up a new specification ~ is that people could choose to make an obvious public record of what their donations are (or not! as it's a choice), and if they did, they could tally up their microdonations for deductions purposes at the end of the year (or not! if they chose anonymity in their transactions under ABIS).]  Choice and consent should also be an objective of any process which offers something better (like anonymity) to the user.  And I think also the Foundation Board, dues-paying members, developers, and everyone can help anonymity happen with bitcoin while preserving that choice.  

In another thread, I've asked the following questions:


I'd love to hear the Zerocash developers respond to this, obviously, and anyone else interested I would really appreciate your thoughts.
Some of my own ideas to support basic bitcoin development generally _and_ progress on the anonymity side are shown at:
https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/issues/19

(brief edit:  I also feel that this is worthy of attention....
https://tahoe-lafs.org/pipermail/tahoe-dev/2014-May/009062.html (from zooko) and see also the following statements regarding multiparty computation setup in zerocash
https://twitter.com/matthew_d_green/status/472208415867928576 h/t zooko, matthewdgreen)

OK, so I feel like I've said more than enough on this....  I look forward to your thoughts, replies, ideas.

https://bittrex.com/Market/Index?MarketName=BTC-XZC
congrats :)

price so high added in exchenge C-cex also https://c-cex.com/?p=zcoin-btc

I wonder who would use a coin that depends on the good will of the developers to destroy a file that contains access to the supply and so on (the so called masterkey).

I guess I should have bought some tho, those things tend to pump so much. Now, who knows if the pump is over and it will instadump as soon as it gets on Poloniex.