Quote from: topman21 on October 19, 2014, 07:52:10 AM

So which is better lol?. Coinswap or coinjoin?. Huh

Thanks.

I agree with prior commenters ~ having both [CoinSwap and Coinjoin) available (in wallet, I think) would be good. With support gradually being added in different wallets and cryptosystems for stealth send, what is available in combination will be significant.

[Note: I am aware that Stealth transaction technology (https://sx.dyne.org/stealth.html), a strong privacy development, has been incorporated into Vertcoin (https://vertcoin.org/) and Shadowcoin (http://www.shadowcoin.co/), with the latter coin type also incorporating an implementation of zk-snarks, which provides anonymity. Stealth send is also becoming available for Electrum (https://github.com/spesmilo/electrum/pull/817) ~ beyond that, I'm not sure where stealth is actually supported, but if you know of more examples by all means please add them here.]

If not directly in wallet, then one could design a plugin (am thinking of the Electrum mixer plugin example, here, though Electrum also has greenaddress and coinapult plugins you could examine):

Quote from: BkkCoins on November 23, 2013, 10:13:29 AM

I've updated the mixer to work independently of Electrum mainline now. As long as you have the latest version you can now simply drop the mixer.py file into your plugins folder and it will be available and can be enabled. It no longer needs a separate fork or Electrum version.
The standalone mixer plugin file is now:
https://github.com/tkhaew/electrum/blob/mixer_plugin/plugins/mixer.py
The default folder where this is can be dropped (on my Ubuntu system anyway) is:
/usr/local/lib/python2.7/dist-packages/Electrum-1.9.5-py2.7.egg/electrum_plugins/
( though the version number could be different )

Regarding the details of 'byzantine cycle mode,' after reading the description and paper, it is my sense that it will also serve tremendously useful for implementation of trans-identical proposals which incorporate 'facet-based' and/or multisignature-oriented anonymous-option identity-related implementations. Repeating part of the original post below:

Quote from: sundance on August 22, 2014, 05:26:38 PM

As part of a new open source implementation project, I've written a research paper presenting a new, complentary protocol to increase anonymity to Bitcoin.
The preliminary paper is the first of two papers describing the algorithmic underpinnings of the project, building on ideas from this forum (CoinJoin, CoinSwap, CoinShuffle, and atomic transfers)
The new algorithm, called Byzantine Cycle Mode, extends the application of Bitcoin mixing primitives (CoinJoin, etc) to large numbers of players mixing unequal inputs. I use an analogy to how encryption modes such as CTR and CBC extend the application of block ciphers (AES, 3DES) to large inputs of non whole block sizes.
Abstract:

Quote

We present a new distributed algorithm, called Byzantine Cycle Mode (BCM), that mixes bitcoins of different sizes. Most known decentralized, riskless Bitcoin mixing algorithms (CoinShuffle, CoinShift, DarkWallets CoinJoin) either require the numbers of bitcoin being mixed to be equal or their anonymity strongly depends on it. Some also do not scale easily to large number of players. BCM relaxes these constraints by transforming large instances with unequal bitcoin amounts into smaller sub-instances on equal amounts allowing players to mix using the known algorithms while preserving their degree of semantic security.

Appreciate feedback.

(...)

My (very generalized) feedback statement is that this is an excellent idea, thus I've linked to the discussion and paper in my Trans-Identical post at the Unsystem forum, which I originally created to simply to discuss possible 'trans-identical' possibilities, but which I now also see as being a launchpad to help defeat the Windhover regulation principle (the pro-regulatory element of Windhover). ~ The idea of tying regulation to decentralized identity is anathema to everything that we should stand for in this community, and just as CoinValidation was defeated by digital fire (in that case, by CoinJoin), so now must we also support and develop technology to defeat the Windhover regulation principle.

The Unsystem forum post I refer to is here:
https://forum.unsystem.net/t/interoperability-and-trans-identical-identity-decentralization-proposals-thoughts-for-review/333/4?u=abisprotocol

I also wanted to address the question that arose relating to Zerocash, here:

Quote from: coins101 on August 31, 2014, 12:37:31 PM

Quote from: alwinlinzee on August 28, 2014, 12:14:54 PM

A viable trust still persist in the use of Zerocash so i suggest you check it out.

I don't really understand this post.

Are you saying that the initial release requires an element of trust at launch?

(...)

It was my understanding that the concerns regarding element of trust needed to launch zerocash were being planned to be ameliorated via some sort of multiparty mechanism, so that there would not actually be a single party that someone would have to trust somehow to kickstart zerocash. I'm not sure if I have the right twitter thread on it, but I believe this was related to it:
This one alludes to a multiparty computation protocol (yes, he's a zerocash dev)
https://twitter.com/matthew_d_green/status/448856221765095426
And this one refers to the multiparty computation protocol being developed for the setup itself, as I alluded to above:
https://twitter.com/matthew_d_green/status/472208415867928576

Note ~ I am not on the Zerocash team or affiliated with it but I am in full support of their proposals. They have been subjected to tremendous scrutiny. It's my understanding that zerocash is going open source (like zerocoin/libzerocoin already is though that's different), but I don't know when that will happen with zerocash, so ask the devs or keep checking their website (http://zerocash-project.org/).