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#msg2420768The 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.
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:
https://twitter.com/matthew_d_green/status/401798811070107648We designed a new version of Zerocoin that reduces proof sizes by 98% and allows for direct anonymous payments that hide payment amount.
Is a 98% reduction in proof size enough to overcome any existing valid reasons to not merge ZeroCoin functionality?
And this:
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.
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:
(...)
As a member, I'd like to see that change.
As a member you're free to ask— though a better forum might be the foundation forum. Since this isn't the foundation's current area of interest I'd expect you'd see more success elsewhere with less effort though.
I really don't see how the Foundation can just stare slack-jawed at the developments in NY (USA), not to mention China, the Russian Federation, and apart from that, the transnational effects of TISA, and do nothing in the way of funding anonymity in bitcoin development.
The Foundation forum, you say? You have to be joking. There is almost zero support in the Foundation forum for ideas related to anonymity. There are a lot of reasons for that, but some of them have been discussed quite a bit in Issue #10 on the Bylaws repository ~ my initial remarks on it can be found here:
https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/issues/10#issuecomment-45282288I've opened a pull request which is being considered by the Board on that issue, #16 (and as I understand it, #17 will also be considered by the Board).
I do agree with you that there might be more success elsewhere with less effort. But I haven't entirely given up on the idea of a Foundation that could be more responsive to user needs and concerns, including the obvious need for anonymity across the network.
Regarding your ideas that you linked to in your comment at
http://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txton "OUTPUT DISTRIBUTION OBFUSCATION"
I would greatly like to see this (or something like it) become part of people's everyday bitcoin transaction experience.
You're right about Zerocash being untested (it's anticipated to have a release in November or December), although I'm confident that when it is released the issues you've discussed with it will at that point have been addressed more than satisfactorily by the developers.
You mentioned also that you "spent a bit of time making recommendations about how it could be integrated in Bitcoin with them in email and in person— but the people involved seem to be very interested in creating an altcoin specifically as an altcoin." It's my understanding that they felt that they felt an altcoin path was more reasonable because it would be unlikely that the bitcoin development team would ever integrate their anonymity work (even if refined) into bitcoin itself, but perhaps I'm wrong, for as you say, you have e-mailed them and met with them in person about it. So then, what is the obstacle to this happening? I would love to be proved so completely wrong in my assumptions about this matter and have someone from the zerocash team show up on this thread and say in reply somewhere here, "Oh, hey ABISprotocol, you are wrong, we _were_ actually invited to gradually work zerocash into bitcoin, and we're actually confident that there's an opportunity for this to happen at some point down the development road!" However, that's not the sense I get at this time, but it does prompt some questions:
1) If there is an avenue for zerocash developers to work more closely with bitcoin, what does that look like? Does it mean that @imichaelmiers & @matthewdgreen (on github) could be invited to work directly on the bitcoin protocol, and have the ability to make commits along with yourself, Gavin, and others?
2) Because (as I mentioned in my issue in the Bylaws repository on this, issue #19), "basic development of the bitcoin protocol, so as to increase the number of persons who are paid to clear basic development backlog and maintenance, (should be) the highest priority,"
isn't there a way where teams (such as the bitcoin development team and the zerocash team) could join forces to help get funding for this to occur? It seems like the development team has been very vocal about the fact that basic development and maintenance of bitcoin is not well supported or funded (at least not as much as it should be).
3) You suggested that there are other avenues for funding that involve less effort than trying to get the Foundation to change its Bylaws in a way that would enhance such funding. What avenues do you have in mind?
thanks in advance for your answers and for engaging this topic so thoughtfully.
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.
