Topic: Zerocoin when? - page 2. (Read 5011 times)

A "soft fork" is a hack. It means miners know about the new rule and other nodes don't, so those nodes can accept blocks that don't follow the new rules, but eventually those blocks will get re-orged away.

I don't personally like soft forks and think we shouldn't use them. The assumption that appearing in the block chain means the transaction is valid (according to everyone) is pretty fundamental. Breaking that by having transactions that are "valid" except that they're not going to actually be accepted by the majority undermines that principle. And so far there haven't been any compelling reasons to do it. P2SH has turned out to not be used so far, even though at the time it was deemed important enough to not want to wait for a scheduled hard fork. ZeroCoin isn't usable for the reasons gmaxwell cited back in May.

There are lots of ways to improve user privacy that don't involve any kind of fork at all - it'd be weird to use a complicated backwards-incompatible scheme before simpler backwards compatible schemes have been implemented.

Will you expand on how this could be possible?

I don't know the cryptography behind Zerocoin, but - as far as I can see - if bitcoins can move from one address to another via Zerocoin, then all clients need to be able to verify this, right?

Also, it's not clear yet that zerocoin is the best solution. There was a very interesting talk at the conference about SCIP, which would provide a more general zero-knowledge proof subsystem.

And if anonymous mixing is all you want, there are still lighter-weight solutions that achieve that goal.

Plenty of people other than Gavin are perfectly competent to answer this question. I've split your post off of the 0.8.2rc3 thread. Please don't make off-topic posts just to try to reach specific parties.

As zerocoin is currently designed it is not viable as a production component in Bitcoin:

* >40kbyte signatures (the authors of the paper give some hand wave at a DHT but this doesn't meaningfully solve the problems created by enormous transactions: the parties interested in them and all full nodes must transfer them to validate them)
* Requires a trusted party to initialize the accumulator (there may be some multiparty computation trick to avoid this, but it's not clear how to apply one in the context of an anonymous system with users that come and go)
* Accumulator grows forever (unprunable, though you could rotate accumulators at the cost of the anonymity set size)
* Validation that runs on the order of 1-2 transactions per second.

Of course, computers get faster and techniques get better: If some combination of improved technology and improved techniques made it 1000x less intensive relative to now it would be pretty interesting. Also, if threats to fungibility aren't addressed through less expensive mechanisms it may become more interesting even if the cost is still somewhat prohibitive.

FWIW, inclusion of something like zerocoin would not require a hardfork. I believe it could be happily accomplished as a soft forking change. Bitcoin is designed to be extensible and able to incorporate new transaction rules without breaking compatibility.

Posting here in the hopes Gavin sees it...  Are there any plans for a zerocoin hard fork implementation in the future?  Not even the near future, but any future.  Or is that just not at all in the cards?