path: root/65/85ab8ce7320c38e9b72e3ac64e18143731e6c9

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <ctpacia@gmail.com>) id 1XGj31-0001xf-5m
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 Aug 2014 06:25:35 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.47 as permitted sender)
	client-ip=209.85.218.47; envelope-from=ctpacia@gmail.com;
	helo=mail-oi0-f47.google.com; 
Received: from mail-oi0-f47.google.com ([209.85.218.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XGj2z-00038x-Ey
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 Aug 2014 06:25:35 +0000
Received: by mail-oi0-f47.google.com with SMTP id x69so5253054oia.34
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 10 Aug 2014 23:25:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.121.99 with SMTP id lj3mr48547435oeb.44.1407738327940;
	Sun, 10 Aug 2014 23:25:27 -0700 (PDT)
Received: by 10.202.107.7 with HTTP; Sun, 10 Aug 2014 23:25:27 -0700 (PDT)
Received: by 10.202.107.7 with HTTP; Sun, 10 Aug 2014 23:25:27 -0700 (PDT)
In-Reply-To: <8137823.B0x87S28xY@calzone>
References: <8137823.B0x87S28xY@calzone>
Date: Mon, 11 Aug 2014 02:25:27 -0400
Message-ID: <CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
From: Chris Pacia <ctpacia@gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Content-Type: multipart/alternative; boundary=047d7b414a8ef942570500549e52
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(ctpacia[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.0 T_TVD_FUZZY_SECURITIES BODY: T_TVD_FUZZY_SECURITIES
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XGj2z-00038x-Ey
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin
 without trusted third parties
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 06:25:35 -0000

--047d7b414a8ef942570500549e52
Content-Type: text/plain; charset=UTF-8

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.

You could skip the verification part and if the inputs turn out to be
invalid then you'll find out when it doesn't confirm. This would problem
open the protocol up to dos attacks and prevent part of the "blame" phase
from working properly.

Alternatively you can have the participants submit the merkle proof for the
input. This would require inputs to have at least one confirmation, however.
On Aug 6, 2014 6:42 PM, "Tim Ruffing" <tim.ruffing@mmci.uni-saarland.de>
wrote:

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

--047d7b414a8ef942570500549e52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"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 t=
he p2p variety) cannot perform this check.=C2=A0 </p>
<p dir=3D"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. Thi=
s would problem open the protocol up to dos attacks and prevent part of the=
 &quot;blame&quot; phase from working properly.</p>

<p dir=3D"ltr">Alternatively you can have the participants submit the merkl=
e proof for the input. This would require inputs to have at least one confi=
rmation, however.</p>
<div class=3D"gmail_quote">On Aug 6, 2014 6:42 PM, &quot;Tim Ruffing&quot; =
&lt;<a href=3D"mailto:tim.ruffing@mmci.uni-saarland.de">tim.ruffing@mmci.un=
i-saarland.de</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
Hey,<br>
<br>
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 CoinJ=
oin<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 explaine=
d<br>
here: <a href=3D"https://bitcointalk.org/index.php?topic=3D279249.0" target=
=3D"_blank">https://bitcointalk.org/index.php?topic=3D279249.0</a> )<br>
<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<b=
r>
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 t=
his<br>
is not the case, the user can just refuse to sign the transaction and nothi=
ng<br>
(bad) happens.<br>
<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 mix=
ing is<br>
useless. A naive approach is to send these two messages via a secure channe=
l<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<b=
r>
which input addresses belong to which output addresses.<br>
<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=3D"http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/" targe=
t=3D"_blank">http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/</a><=
br>
<br>
Moreover, for the full details, have a look at the research paper on<br>
CoinShuffle that can be found here:<br>
<a href=3D"http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshu=
ffle.pdf" target=3D"_blank">http://crypsys.mmci.uni-saarland.de/projects/Co=
inShuffle/coinshuffle.pdf</a><br>
<br>
The paper has been accepted at a major European academic conference on<br>
security (ESORICS). We will present the idea there.<br>
<br>
Our Proof-of-concept Implementation<br>
-----------------------------------<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 on=
ly<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 goa=
l<br>
was to demonstrate feasibility and estimate the performance of our approach=
.<br>
<br>
<br>
Our Future Plans<br>
----------------<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. Si=
nce<br>
we do not have much experience in the design of existing Bitcoin clients, w=
e<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 th=
is<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>
<br>
CoinShuffle Features<br>
--------------------<br>
CoinShuffle has the following features:<br>
<br>
=C2=A0- 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>
<br>
<br>
=C2=A0- 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>
<br>
(This is not a weakness: If there is only one honest participant, meaningfu=
l<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 ca=
n<br>
immediately determine the output address of the honest participant.)<br>
<br>
=C2=A0- 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>
<br>
=C2=A0- 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 counte=
red<br>
in CoinShuffle.<br>
<br>
While in case of disruption, the current run of the protocol has to stop,<b=
r>
CoinShuffle addresses this problem as follows: =C2=A0In case of active disr=
uption,<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 t=
he<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 th=
e<br>
presence of malicious participant (although this can take quite a while the=
n).<br>
<br>
=C2=A0- Only public-key encryption and signatures:<br>
The protocol requires only well-established cryptographic primitives. Besid=
es<br>
signatures and hash functions (that are already used by Bitcoin), only<br>
standard public-key encryption is necessary.<br>
<br>
=C2=A0- 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>
<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, generi=
c<br>
constructions cannot be used in practice yet, because the computation and<b=
r>
communication costs are huge.)<br>
<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=
>
<br>
<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=3D"https://twitter.com/comefrombeyond/status/485429369268350977" ta=
rget=3D"_blank">https://twitter.com/comefrombeyond/status/48542936926835097=
7</a> )<br>
<br>
<br>
TL,DR:<br>
Mixing is the way to improve anonymity in Bitcoin now, as it does not requi=
re<br>
changes to the Bitcoin protocol. We propose CoinShuffle, a decentralized<br=
>
protocol to perform mixing in a secure way without trusted third parties, s=
ee<br>
<a href=3D"http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/" targe=
t=3D"_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, critici=
sm,<br>
and improvements for the protocol itself.<br>
<br>
Best,<br>
Tim Ruffing, Pedro Moreno-Sanchez, Aniket Kate<br>
<br>-----------------------------------------------------------------------=
-------<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=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D153845071&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D153845071&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>

Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>

--047d7b414a8ef942570500549e52--