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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1XGt3i-0000rB-7N
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 17:06:58 +0000
Received: from mail-qc0-f178.google.com ([209.85.216.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XGt3e-000844-Di
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 17:06:58 +0000
Received: by mail-qc0-f178.google.com with SMTP id x3so1802569qcv.37
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Aug 2014 10:06:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=nog5N5XC9aOHADAdnopDjLiHLHYTHRCtpxfIp7ObZ/4=;
b=beE85SaHF5kkK5K15TjvYHRK4gVFGdPjYi4OaeJ/BcsemMDrA/151ki4XB0Aj+dFTQ
2uupe5Ca5MBiCNQtKbE2i3csUpj2kDO/PT/ORrwGmBKy15e0WYUvPWogCJXz+VrdRWu5
tpzJIMRIA/gPvUK6ISJJUNWlfPjDuD/Tt6B9FjP+XVdCTRQtENAYN3VFBXgoeNuEQnq7
tqL68BIf7Q0U2s0Sm/63T5oA6WHi+Cdfl8y9xkb7N3K2YzlPx9KNfxUWQjEkeqbZZzPv
VQ6E97y0jP+f6IVqWSewmJV17wC0RJGZtMW7CSg1wUY8g4nKiWh/ivRJ0ounXb8IcX5u
rxPg==
X-Gm-Message-State: ALoCoQmuxM7X5OK2a8nndkNX3nrRNAb8EL0togHpdmu8Oc792FayW18NhIZYjVRo7RXHpa6ZAsJs
MIME-Version: 1.0
X-Received: by 10.224.123.8 with SMTP id n8mr66016109qar.40.1407776808771;
Mon, 11 Aug 2014 10:06:48 -0700 (PDT)
Received: by 10.140.47.175 with HTTP; Mon, 11 Aug 2014 10:06:48 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <1446506.FNP3GnOpud@calzone>
References: <8137823.B0x87S28xY@calzone>
<CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
<CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
<1446506.FNP3GnOpud@calzone>
Date: Mon, 11 Aug 2014 10:06:48 -0700
Message-ID: <CACh7GpEBocaOdKNEkWXBusyUvin73P+JvjnnZF0m8f7DmJhcvA@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Content-Type: multipart/alternative; boundary=089e0149ca709c3c8e05005d944b
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1XGt3e-000844-Di
Cc: "bitcoin-development@lists.sourceforge.net"
<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 17:06:58 -0000
--089e0149ca709c3c8e05005d944b
Content-Type: text/plain; charset=UTF-8
There should not be a requirement at this level to ensure validity. That
would too constrain use cases of implementations of your protocol. It is
not difficult to imagine use cases where parties generate chained
transactions on top of unconfimed transactions. Although malleability
currently makes this difficult to do safely in general, it is not
inconceivable that there are circumstances where it would nevertheless be
safe or otherwise desireable.
It is a good security recommendation that clients validate the inputs to a
shuffle they are participating in. What this means depends on the client --
checking the UTXO set for a full node, making some getutxos queries for a
SPV client. But this should remain a recommendation, not a requirement.
On Mon, Aug 11, 2014 at 4:38 AM, Tim Ruffing <
tim.ruffing@mmci.uni-saarland.de> wrote:
> 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.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e0149ca709c3c8e05005d944b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>There should not be a requirement at this level to en=
sure validity. That would too constrain use cases of implementations of you=
r protocol. It is not difficult to imagine use cases where parties generate=
chained transactions on top of unconfimed transactions. Although malleabil=
ity currently makes this difficult to do safely in general, it is not incon=
ceivable that there are circumstances where it would nevertheless be safe o=
r otherwise desireable.<br>
<br></div>It is a good security recommendation that clients validate the in=
puts to a shuffle they are participating in. What this means depends on the=
client -- checking the UTXO set for a full node, making some getutxos quer=
ies for a SPV client. But this should remain a recommendation, not a requir=
ement.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
Aug 11, 2014 at 4:38 AM, Tim Ruffing <span dir=3D"ltr"><<a href=3D"mail=
to:tim.ruffing@mmci.uni-saarland.de" target=3D"_blank">tim.ruffing@mmci.uni=
-saarland.de</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hmm, you are right. Lightweight clients are =
an interesting point, we have to<br>
think about a policy for them.<br>
<br>
As you said, the worst case is that the tx will not confirm. So the only<br=
>
possible attack is DoS. For clients that rely on servers it's reasonabl=
e to<br>
trust their servers not to perform DoS. (Anyway, the servers could do worse=
<br>
attacks.)<br>
<br>
For SPV-clients (without servers), I'm not sure at the moment. Somethin=
g like<br>
getUTXO seems to be a possibility. I think even SPV-clients can verify the<=
br>
validity of the tx that created the input that is designated for mixing. Th=
en<br>
the only remaining reason why it could be invalid is that the input could h=
ave<br>
been spent already otherwise. But in this case, only one honest client with=
<br>
full information would suffice: a signed transaction that spends the money<=
br>
would convince even SPV-clients that the participant with this inputs tries=
to<br>
cheat. This transaction could even be provided by lightweight client that g=
ot<br>
if from a server; the transaction is signed by the cheating participant<br>
anyway.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Monday 11 August 2014 02:30:16 Chris Pacia wrote:<br>
> Actually getUTXO would probably work here as well. It isn't authen=
ticated<br>
> but it should be good enough for this purpose. The worst that would ha=
ppen<br>
> is the tx doesn't confirm.<br>
><br>
> On Aug 11, 2014 2:25 AM, "Chris Pacia" <<a href=3D"mailto=
:ctpacia@gmail.com">ctpacia@gmail.com</a>> wrote:<br>
> > One issue I do see is the protocol requires participants to check=
the<br>
> > inputs submitted by others are valid. Lite clients (at least of t=
he p2p<br>
> > variety) cannot perform this check.<br>
> ><br>
> > You could skip the verification part and if the inputs turn out t=
o be<br>
> > invalid then you'll find out when it doesn't confirm. Thi=
s would problem<br>
> > open the protocol up to dos attacks and prevent part of the "=
;blame" phase<br>
> > from working properly.<br>
> ><br>
> > Alternatively you can have the participants submit the merkle pro=
of for<br>
> > the input. This would require inputs to have at least one confirm=
ation,<br>
> > however.</div></div><br>-----------------------------------------=
-------------------------------------<br>
<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><br></div>
--089e0149ca709c3c8e05005d944b--
|
