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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tim.ruffing@mmci.uni-saarland.de>)
id 1XGnwB-0004Sf-Gv for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 11:38:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of
mmci.uni-saarland.de designates 139.19.1.49 as permitted
sender) client-ip=139.19.1.49;
envelope-from=tim.ruffing@mmci.uni-saarland.de;
helo=hera.mpi-klsb.mpg.de;
Received: from infao0809.mpi-klsb.mpg.de ([139.19.1.49]
helo=hera.mpi-klsb.mpg.de)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1XGnw9-0005Kz-QB
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 11:38:51 +0000
Received: from zak.mpi-klsb.mpg.de ([139.19.1.29]:54225)
by hera.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtp (Exim 4.80) id 1XGnw0-0005pS-BQ;
Mon, 11 Aug 2014 13:38:42 +0200
Received: from [141.70.80.5] (port=45471 helo=calzone.localnet)
by zak.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
(Exim 4.80) id 1XGnvz-0007lO-Vu; Mon, 11 Aug 2014 13:38:40 +0200
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Chris Pacia <ctpacia@gmail.com>
Date: Mon, 11 Aug 2014 13:38:39 +0200
Message-ID: <1446506.FNP3GnOpud@calzone>
User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
References: <8137823.B0x87S28xY@calzone>
<CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
<CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart140776882.gREGzQnYAN";
micalg="pgp-sha1"; protocol="application/pgp-signature"
X-MPI-Local-Sender: true
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
-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: 1XGnw9-0005Kz-QB
Cc: 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 11:38:51 -0000
--nextPart140776882.gREGzQnYAN
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Hmm, you are right. Lightweight clients are an interesting point, we have to
think about a policy for them.
As you said, the worst case is that the tx will not confirm. So the only
possible attack is DoS. For clients that rely on servers it's reasonable to
trust their servers not to perform DoS. (Anyway, the servers could do worse
attacks.)
For SPV-clients (without servers), I'm not sure at the moment. Something like
getUTXO seems to be a possibility. I think even SPV-clients can verify the
validity of the tx that created the input that is designated for mixing. Then
the only remaining reason why it could be invalid is that the input could have
been spent already otherwise. But in this case, only one honest client with
full information would suffice: a signed transaction that spends the money
would convince even SPV-clients that the participant with this inputs tries to
cheat. This transaction could even be provided by lightweight client that got
if from a server; the transaction is signed by the cheating participant
anyway.
Tim
On Monday 11 August 2014 02:30:16 Chris Pacia wrote:
> Actually getUTXO would probably work here as well. It isn't authenticated
> but it should be good enough for this purpose. The worst that would happen
> is the tx doesn't confirm.
>
> On Aug 11, 2014 2:25 AM, "Chris Pacia" <ctpacia@gmail.com> wrote:
> > 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.
--nextPart140776882.gREGzQnYAN
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
iQGcBAABAgAGBQJT6Ks/AAoJEKAmVAtPJmh7o2sL/3SHsMrAnX/EGwWOMf1/tIpq
p65SZecMtJChSIic411M/h14uHn8DZ3faWhetj89/VHv3GSgGE4tpwk+9AYfEss5
NfdRzBlrJ80tu7vxmfat3HfwtZl+AzYA/omioIynW6s9Mat47HQzAINFajCvVq/i
U9WfYaJnMgd2ruic6eGQYiBRZKregCpVIV9yxqFJtFNWpkODY8JHw3R+FUbNutQI
69p9DS5iAx8BWLOPsAqq9vBivkwiDcRtfc2AyminxO6KzcmfAKFGZie30M5IFd9a
hysS7fdBJPjXw9yY+voWFr92bCP4Cc6IWpP5IXPNGJ8vfbPQjBLe2PPcxEto7d7j
zAF3HBpfdFC6OJ+mh+kaQ0ooF1HN4Rz7H2yRe7VLK1loVT+hToULTqrEVnKVnWUM
6Y8wP4TaQQZjnyqeJAoDLpQG6hihBOe6l2pjosefyZqO1NCgHwDuJ73tDMfmzPIH
huus7jeC/qkcTSZ7mtOlHPmRpCDBgOxf82S7WFMrcA==
=SNhx
-----END PGP SIGNATURE-----
--nextPart140776882.gREGzQnYAN--
|
