<p dir="ltr">Actually getUTXO would probably work here as well. It isn&#39;t authenticated but it should be good enough for this purpose. The worst that would happen is the tx doesn&#39;t confirm. </p>
<div class="gmail_quote">On Aug 11, 2014 2:25 AM, &quot;Chris Pacia&quot; &lt;<a href="mailto:ctpacia@gmail.com">ctpacia@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">One issue I do see is the protocol requires participants to check the inputs submitted by others are valid. Lite clients (at least of the p2p variety) cannot perform this check.  </p>
<p dir="ltr">You could skip the verification part and if the inputs turn out to be invalid then you&#39;ll find out when it doesn&#39;t confirm. This would problem open the protocol up to dos attacks and prevent part of the &quot;blame&quot; phase from working properly.</p>

<p dir="ltr">Alternatively you can have the participants submit the merkle proof for the input. This would require inputs to have at least one confirmation, however.</p>
<div class="gmail_quote">On Aug 6, 2014 6:42 PM, &quot;Tim Ruffing&quot; &lt;<a href="mailto:tim.ruffing@mmci.uni-saarland.de" target="_blank">tim.ruffing@mmci.uni-saarland.de</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

We (a group of researchers in Germany) propose a decentralized protocol for<br>
CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is<br>
called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin<br>
in the original spirit of Bitcoin, i.e., decentralized and without trusted<br>
third parties. (If you are not familiar with CoinJoin, the idea is explained<br>
here: <a href="https://bitcointalk.org/index.php?topic=279249.0" target="_blank">https://bitcointalk.org/index.php?topic=279249.0</a> )<br>
The protocol is essentially a clever way to create a CoinJoin transaction.<br>
Recall that the idea of CoinJoin is mixing with one SINGLE transaction that<br>
has multiple input addresses and multiple fresh output addresses (i.e., one<br>
pair of addresses per user). The advantage of CoinJoin over mixing with a<br>
server or trusted party is that nobody can steal coins. Each user can check if<br>
the single transaction sends enough coins to his fresh output address. If this<br>
is not the case, the user can just refuse to sign the transaction and nothing<br>
(bad) happens.<br>
The difficulty in CoinJoin is to let the participants announce their fresh<br>
output addresses without breaking anonymity: Of course, if a participant of<br>
the protocol just announces &quot;I have 1 BTC at address X now&quot; and &quot;I would like<br>
to have it back at address Y&quot;, then everybody can link X and Y and mixing is<br>
useless. A naive approach is to send these two messages via a secure channel<br>
to a server that organizes the whole mixing. While the server cannot steal<br>
coins, the server still has to be trusted for anonymity, because it knows<br>
which input addresses belong to which output addresses.<br>
We present the list of CoinShuffle&#39;s features at the end of this e-mail. An<br>
overview over the technical details can be found on the project page:<br>
<a href="http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/" target="_blank">http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/</a><br>
Moreover, for the full details, have a look at the research paper on<br>
CoinShuffle that can be found here:<br>
<a href="http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf" target="_blank">http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf</a><br>
The paper has been accepted at a major European academic conference on<br>
security (ESORICS). We will present the idea there.<br>
Our Proof-of-concept Implementation<br>
There is a proof-of-concept implementation (written in Python) available on<br>
our project page. It is really only a proof-of-concept and it implements only<br>
the announcement of the addresses, not the creation of the transaction.<br>
Moreover, the code is CERTAINLY INSECURE and not well-written; our only goal<br>
was to demonstrate feasibility and estimate the performance of our approach.<br>
Our Future Plans<br>
Now we are planning a full, open-source implementation of the protocol. Of<br>
course, we would like to build on top of an existing wide-spread client. Since<br>
we do not have much experience in the design of existing Bitcoin clients, we<br>
would appreciate any help in the process. In particular, we did not decide<br>
which of the existing clients we would like to extend. Any hints towards this<br>
decisions would very helpful. Help in design and coding would be great but we<br>
also would like to hear your comments, criticism, and improvements for the<br>
protocol itself.<br>
CoinShuffle Features<br>
CoinShuffle has the following features:<br>
 - Decentralization / no third party:<br>
There is no (trusted or untrusted) third party in a run of the protocol.<br>
(Still, as in all mixing solutions, users need some way to gather together<br>
before they can run the protocol. This can be done via a P2P protocol if a<br>
decentralized solution is desired also for this step.)<br>
 - Unlinkability of input and output addresses:<br>
Nobody, in particular no server (there is none!), can link input and output<br>
addresses of a mixing transaction, as long as there are at least two honest<br>
participants in run of the protocol.<br>
(This is not a weakness: If there is only one honest participant, meaningful<br>
mixing is just impossible, no matter how it is organized. If all the other<br>
participants collude, they know all their input and output addresses and can<br>
immediately determine the output address of the honest participant.)<br>
 - Security against thefts:<br>
As explained above, nobody can steal coins during the mixing because of the<br>
CoinJoin principle.<br>
Every participant can verify that his money will not be stolen. Otherwise, he<br>
refuses to sign the transaction and nothing will happen.<br>
 - Robustness against denial-of-service:<br>
In CoinJoin, a single malicious (or malfunctioning) client suffices to stop<br>
the whole protocol (e.g., by just refusing to sing the transaction without a<br>
proper reason.) This can easily lead to DoS attacks but these can be countered<br>
in CoinShuffle.<br>
While in case of disruption, the current run of the protocol has to stop,<br>
CoinShuffle addresses this problem as follows:  In case of active disruption,<br>
i.e., some participant sends wrong messages, the protocol provides a proof of<br>
this misbehavior. Then the honest protocol parties can start a new run of the<br>
protocol without the misbehaving participant. Also in case of passive<br>
disruption, i.e., some participant does not respond (for whatever reason), the<br>
remaining participants can agree on starting a new run without this<br>
participant. This ensures that the protocol will finally succeed even in the<br>
presence of malicious participant (although this can take quite a while then).<br>
 - Only public-key encryption and signatures:<br>
The protocol requires only well-established cryptographic primitives. Besides<br>
signatures and hash functions (that are already used by Bitcoin), only<br>
standard public-key encryption is necessary.<br>
 - Efficiency:<br>
A run of the protocol with 30 participants takes less than 100 seconds (in a<br>
setting with reasonable bandwidth and delay). This is not much, given that 10<br>
min (on average) are required to confirm the mixing transaction anyway.<br>
The costs are almost completely caused by communication. The computation<br>
overhead is minimal. (This is the main achievement actually. In theory, it is<br>
clear that a protocol with all the properties can be built. However, generic<br>
constructions cannot be used in practice yet, because the computation and<br>
communication costs are huge.)<br>
- Compatibility:<br>
As CoinShuffle works on top of Bitcoin, it is fully compatible with the<br>
current Bitcoin system. No changes to the Bitcoin protocol are required.<br>
By the way: The NXT cryptocurrency picked up our idea and an implementation of<br>
CoinShuffle for a part of NXT is under way. (<br>
<a href="https://twitter.com/comefrombeyond/status/485429369268350977" target="_blank">https://twitter.com/comefrombeyond/status/485429369268350977</a> )<br>
Mixing is the way to improve anonymity in Bitcoin now, as it does not require<br>
changes to the Bitcoin protocol. We propose CoinShuffle, a decentralized<br>
protocol to perform mixing in a secure way without trusted third parties, see<br>
<a href="http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/" target="_blank">http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/</a> for a technical<br>
overview. Our next step is to implement the protocol. Help in design and<br>
coding would be great but we also would like to hear your comments, criticism,<br>
and improvements for the protocol itself.<br>
Tim Ruffing, Pedro Moreno-Sanchez, Aniket Kate<br>
Infragistics Professional<br>
Build stunning WinForms apps today!<br>
Reboot your WinForms applications with our WinForms controls.<br>
Build a bridge from your legacy apps to the future.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=153845071&amp;iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=153845071&amp;iu=/4140/ostg.clktrk</a><br>_______________________________________________<br>

Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>