summaryrefslogtreecommitdiff
path: root/2a/287123f26140c3dc89794b563c2c6b7de27a77
blob: 105294f05e1cc6c6ff1229fc091d415e0e7d76f8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <xor@freenetproject.org>) id 1XFNar-0002bz-DA
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 Aug 2014 13:18:57 +0000
X-ACL-Warn: 
Received: from smtprelay03.ispgateway.de ([80.67.31.26])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1XFNap-0002HG-Pi
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 Aug 2014 13:18:57 +0000
Received: from [89.13.171.157] (helo=anonymous)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68) (envelope-from <xor@freenetproject.org>)
	id 1XFNIq-0002G4-Ck; Thu, 07 Aug 2014 15:00:20 +0200
From: xor <xor@freenetproject.org>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 07 Aug 2014 15:00:11 +0200
Message-ID: <1530801.palqu9XdN4@1337h4x0r>
Organization: Freenet Project
User-Agent: KMail/4.13.2 (Linux/3.13.0-32-generic; KDE/4.13.2; x86_64; ; )
In-Reply-To: <8137823.B0x87S28xY@calzone>
References: <8137823.B0x87S28xY@calzone>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart20408252.l0l1QHbILQ";
	micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Df-Sender: eG9yQGZyZWVtYWlsLmJvZ2VydC5kZQ==
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.67.31.26 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
X-Headers-End: 1XFNap-0002HG-Pi
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
Reply-To: xor@freenetproject.org
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: Thu, 07 Aug 2014 13:18:57 -0000


--nextPart20408252.l0l1QHbILQ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

On Thursday, August 07, 2014 12:22:31 AM Tim Ruffing wrote:
>  - Decentralization / no third party:
> There is no (trusted or untrusted) third party in a run of the protoc=
ol.
> (Still, as in all mixing solutions, users need some way to gather tog=
ether
> before they can run the protocol. This can be done via a P2P protocol=
 if a
> decentralized solution is desired also for this step.)
[...]
> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ for a techn=
ical
> overview.=20

I think the description at your website leaves out the truly interestin=
g part:
How do you decentralize this securely?
=2D How do Alice, Bob, Charlie and Dave communicate, i.e. which network i=
s used=20
for communication and how?
=2D How does Alice know that Bob, Charlie and Dave are not the same perso=
n?
(=3D how do you prevent a Sybil attack?)

Because thats the real problem with mixing it seems - ensuring that you=
r=20
mixing partners are actually 100 people and not just 1 attacker. There =
are=20
probably many mixing algorithms which work if you solve that problem, b=
ut I=20
don't see how you offer a solution for it :(
--nextPart20408252.l0l1QHbILQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAABCAAGBQJT43hhAAoJEMtmZ+8tjWt53aAP/068oZ1yLxjv34+sg2OumY94
y5F4SaNZ4mO9N4Z7NT1Ef0TTgn/XTA3wg02xsedGQH4Cq5P5/SnRwfeNoPJZLsyD
Sg+9iYeuosxXxTpHJrEhVY9x0RH3hmQf5KHc3kgmC339SlCQZm/53yOemE7H89d9
gnkxfd5ig7a3z5+kerDrpPbqrcgR6o+3Gp7rca7CUalL6A4r50OysNKDMqMQy6xl
eiaBBBZhLZfooLFzBN5Zzdo2I9eUCmiaw/YR/ChaujH05kNAeXMpjGb6cLS7eIhw
1HWpp9MMZknFZtP7BckGtqwZA2DykhN4sWT2BEmVkx4mtylNBdIK0+POF5So4ZOH
PGQlHjmUfa25G6s+ZcK7j9kF7HK7ThwTrZJLpVliF/+B7jQx13M79cceOgRfBIU3
LU0Vl0Ta1H4lqUd4kybEAcQxF+eDsW8yKYvUP/mVsTkodfjsSJ4lO3/lTeF/1/71
PuNe9FEQ1prHVd0kDLrYOQjkW1/skGBKdGDpUvRZPWNsW2ZfVzf4UlGVxhK5R/hc
RiR2tu1ikkJdrKbJu3r3YpM5gC4Df1mlXs4JWWwJrk5iJZPpSvoV0BC8lPA6YR8G
XP4dIEMDq2VZvi2JQjCd1lASJrkPvbmwgqvJnVTiaECTV/wMtXF2EaZxWCULnW/C
XzdreizsP4+Ip/8AJuTL
=5oUV
-----END PGP SIGNATURE-----

--nextPart20408252.l0l1QHbILQ--