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
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1Z6TFr-0005GD-35
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 00:36:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.47 as permitted sender)
client-ip=209.85.220.47; envelope-from=elombrozo@gmail.com;
helo=mail-pa0-f47.google.com;
Received: from mail-pa0-f47.google.com ([209.85.220.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6TFp-0003hM-Oe
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 00:36:59 +0000
Received: by padev16 with SMTP id ev16so109334002pad.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 17:36:52 -0700 (PDT)
X-Received: by 10.68.57.130 with SMTP id i2mr45479655pbq.95.1434847012114;
Sat, 20 Jun 2015 17:36:52 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by mx.google.com with ESMTPSA id
cp10sm15368509pdb.44.2015.06.20.17.36.48
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 20 Jun 2015 17:36:51 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <6d025db96e7aec4e6e47a76883a9a1e3@riseup.net>
Date: Sat, 20 Jun 2015 17:36:47 -0700
Message-Id: <BDEEE2FF-7B42-46B6-9071-E753A594F93E@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
<04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
<812d8353e66637ec182da31bc0a9aac1@riseup.net>
<1727885.UUNByX4Jyd@crushinator>
<83A7C606-B601-47D2-BE10-2A1412D97514@gmail.com>
<CABm2gDrHFB_XtQXVvoFeEH5TUfWSc3JLcNuo-oSXNJaExB+Vdg@mail.gmail.com>
<8a49c53a032503eeca4f51cdef725fe1@riseup.net>
<B4B8DB86-C03A-4C79-BD94-3E073D5E7003@gmail.com>
<6d025db96e7aec4e6e47a76883a9a1e3@riseup.net>
To: justusranvier@riseup.net
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -0.8 (/)
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
(elombrozo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
-0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6TFp-0003hM-Oe
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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: Sun, 21 Jun 2015 00:36:59 -0000
--Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C
Content-Type: multipart/alternative;
boundary="Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156"
--Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Jun 20, 2015, at 5:27 PM, justusranvier@riseup.net wrote:
>=20
> Signed PGP part
> On 2015-06-20 19:19, Eric Lombrozo wrote:
> >> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup.net wrote:
> >>
> >> Signed PGP part
> >> On 2015-06-20 18:20, Jorge Tim=C3=B3n wrote:
> >> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo =
<elombrozo@gmail.com>
> >> > wrote:
> >> >> If we want a non-repudiation mechanism in the protocol, we =
should
> >> >> explicitly define one rather than relying on =E2=80=9Cprima =
facie=E2=80=9D
> >> >> assumptions. Otherwise, I would recommend not relying on the =
existence
> >> >> of a signed transaction as proof of intent to pay=E2=80=A6
> >> >
> >> > Non-repudiation can be built on top of the payment protocol =
layer.
> >>
> >>
> >> Non-repudiation is an intrinsic property of the ECDSA signatures =
which
> >> Bitcoin uses - it's not a feature that needs to be built.
> >>
> >> There's no way to accidentally sign a transaction and accidentally
> >> announce it publicly. There is no form of third-party error that =
can
> >> result in a payee receiving an erroneous contract.
> >>
> >>
> >
> > Justus,
> >
> > We don=E2=80=99t even have a concept of identity in the Bitcoin =
protocol, let
> > alone non-repudiation. What good is non-repudiation if there=E2=80=99s=
no way
> > to even associate a signature with a legal entity?
> >
> > Sure, we could use the ECDSA signatures in transactions as part of a
> > non-repudiation scheme - but the recipient would have to also have a
> > means to establish the identity of the sender and associate it with
> > the the transaction.
> >
> >
> > Furthermore, in light of the fact that there *are* fully legitimate
> > use cases for sending conflicting transactions=E2=80=A6and the fact =
that
> > determination of intent isn=E2=80=99t always entirely clear=E2=80=A6we=
should refrain
> > from attaching any further significance transaction signatures other
> > than that =E2=80=9Cthe sender was willing to have it included in the
> > blockchain if a miner were to have seen it and accepted it=E2=80=A6but=
perhaps
> > the sender would have changed their mind before it actually did get
> > accepted.=E2=80=9D
>=20
> Bitcoin has no concept of identity, but in any type of commercial
> transaction the parties involved must know some minimal amount of
> identity information in order to transact at all.
>=20
> Except for some identifiable special cases, I think a payee is =
perfectly
> justified in treating a double spend of a payment sent to them as part
> of a commercial transaction as a fraud attempt and employing whatever
> non-Bitcoin recourse mechanisms, if any, they have access to.
>=20
> =46rom the perspective of the network, the obviously correct action =
for
> any node or miner is to relay the first version of any transaction =
they
> see. The primary purpose of mining is to resolve this
> otherwise-unresolvable problem of determining which transaction among =
a
> set of conflicting transactions happened first.
>=20
> If a node or miner wants to deviate from the obviously correct
> behaviour, and if they want to avoid harming the value of the network,
> they should be particularly careful to make sure their deviation from
> "first seen" doesn't introduce harmful unintended side effects, like
> making fraud easier.
>=20
The contract between the buyer and seller is actually outside the =
Bitcoin network. Yes, a merchant that gets cheated could seek some other =
recourse in such an event=E2=80=A6but the behavior you=E2=80=99re =
claiming as =E2=80=9Cobviously correct=E2=80=9D is NOT obviously =
correct. In fact, there are arguments against this =E2=80=9Cobviously =
correct=E2=80=9D way even if we were to accept the premise that the =
signature implies a promise to pay (which I think many reasonable =
individuals would also dispute). For instance, by relaying conflicting =
transactions it makes it potentially easier for others to discover the =
double-spend attempt (of course, this requires wallets to not be lazy =
about this=E2=80=A6perhaps such relays could be flagged or placed in a =
special message type).
- Eric Lombrozo
--Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 20, 2015, at 5:27 PM, <a =
href=3D"mailto:justusranvier@riseup.net" =
class=3D"">justusranvier@riseup.net</a> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><fieldset =
style=3D"padding-top:10px; border:0px; border: 3px solid #CCC; =
padding-left: 20px;" class=3D""><legend style=3D"font-weight:bold" =
class=3D"">Signed PGP part</legend><div style=3D"padding-left:3px;" =
class=3D"">On 2015-06-20 19:19, Eric Lombrozo wrote:<br =
class=3D"">>> On Jun 20, 2015, at 4:37 PM, <a =
href=3D"mailto:justusranvier@riseup.net" =
class=3D"">justusranvier@riseup.net</a> wrote:<br class=3D"">>><br =
class=3D"">>> Signed PGP part<br class=3D"">>> On 2015-06-20 =
18:20, Jorge Tim=C3=B3n wrote:<br class=3D"">>> > On Fri, Jun =
19, 2015 at 6:42 PM, Eric Lombrozo <<a =
href=3D"mailto:elombrozo@gmail.com" =
class=3D"">elombrozo@gmail.com</a>><br class=3D"">>> > =
wrote:<br class=3D"">>> >> If we want a non-repudiation =
mechanism in the protocol, we should<br class=3D"">>> >> =
explicitly define one rather than relying on =E2=80=9Cprima facie=E2=80=9D=
<br class=3D"">>> >> assumptions. Otherwise, I would =
recommend not relying on the existence<br class=3D"">>> >> =
of a signed transaction as proof of intent to pay=E2=80=A6<br =
class=3D"">>> ><br class=3D"">>> > Non-repudiation can =
be built on top of the payment protocol layer.<br class=3D"">>><br =
class=3D"">>><br class=3D"">>> Non-repudiation is an =
intrinsic property of the ECDSA signatures which<br class=3D"">>> =
Bitcoin uses - it's not a feature that needs to be built.<br =
class=3D"">>><br class=3D"">>> There's no way to =
accidentally sign a transaction and accidentally<br class=3D"">>> =
announce it publicly. There is no form of third-party error that can<br =
class=3D"">>> result in a payee receiving an erroneous =
contract.<br class=3D"">>><br class=3D"">>><br =
class=3D"">><br class=3D"">> Justus,<br class=3D"">><br =
class=3D"">> We don=E2=80=99t even have a concept of identity in the =
Bitcoin protocol, let<br class=3D"">> alone non-repudiation. What =
good is non-repudiation if there=E2=80=99s no way<br class=3D"">> to =
even associate a signature with a legal entity?<br class=3D"">><br =
class=3D"">> Sure, we could use the ECDSA signatures in transactions =
as part of a<br class=3D"">> non-repudiation scheme - but the =
recipient would have to also have a<br class=3D"">> means to =
establish the identity of the sender and associate it with<br =
class=3D"">> the the transaction.<br class=3D"">><br =
class=3D"">><br class=3D"">> Furthermore, in light of the fact =
that there *are* fully legitimate<br class=3D"">> use cases for =
sending conflicting transactions=E2=80=A6and the fact that<br =
class=3D"">> determination of intent isn=E2=80=99t always entirely =
clear=E2=80=A6we should refrain<br class=3D"">> from attaching any =
further significance transaction signatures other<br class=3D"">> =
than that =E2=80=9Cthe sender was willing to have it included in the<br =
class=3D"">> blockchain if a miner were to have seen it and accepted =
it=E2=80=A6but perhaps<br class=3D"">> the sender would have changed =
their mind before it actually did get<br class=3D"">> accepted.=E2=80=9D=
<br class=3D""><br class=3D"">Bitcoin has no concept of identity, but in =
any type of commercial<br class=3D"">transaction the parties involved =
must know some minimal amount of<br class=3D"">identity information in =
order to transact at all.<br class=3D""><br class=3D"">Except for some =
identifiable special cases, I think a payee is perfectly<br =
class=3D"">justified in treating a double spend of a payment sent to =
them as part<br class=3D"">of a commercial transaction as a fraud =
attempt and employing whatever<br class=3D"">non-Bitcoin recourse =
mechanisms, if any, they have access to.<br class=3D""><br class=3D"">=46r=
om the perspective of the network, the obviously correct action for<br =
class=3D"">any node or miner is to relay the first version of any =
transaction they<br class=3D"">see. The primary purpose of mining is to =
resolve this<br class=3D"">otherwise-unresolvable problem of determining =
which transaction among a<br class=3D"">set of conflicting transactions =
happened first.<br class=3D""><br class=3D"">If a node or miner wants to =
deviate from the obviously correct<br class=3D"">behaviour, and if they =
want to avoid harming the value of the network,<br class=3D"">they =
should be particularly careful to make sure their deviation from<br =
class=3D"">"first seen" doesn't introduce harmful unintended side =
effects, like<br class=3D"">making fraud easier.<br =
class=3D""></div></fieldset><br class=3D""></div></blockquote></div><br =
class=3D""><div class=3D"">The contract between the buyer and seller is =
actually outside the Bitcoin network. Yes, a merchant that gets cheated =
could seek some other recourse in such an event=E2=80=A6but the behavior =
you=E2=80=99re claiming as =E2=80=9Cobviously correct=E2=80=9D is NOT =
obviously correct. In fact, there are arguments against this =
=E2=80=9Cobviously correct=E2=80=9D way even if we were to accept the =
premise that the signature implies a promise to pay (which I think many =
reasonable individuals would also dispute). For instance, by relaying =
conflicting transactions it makes it potentially easier for others to =
discover the double-spend attempt (of course, this requires wallets to =
not be lazy about this=E2=80=A6perhaps such relays could be flagged or =
placed in a special message type).</div><div class=3D""><br =
class=3D""></div><div class=3D"">- Eric Lombrozo</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div></body></html>=
--Apple-Mail=_E55F652E-24DD-489A-9944-787B5DC86156--
--Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVhgcfAAoJEJNAI64YFENUk6gQAJ34cbEur/arGUQZUjluZXBu
XYxnQLAZ35WjJEVFwZjBaj2KkH9ti2lcIuDJygdvwOc4Fe6+Kq4+rKgLVdQtZpJf
b7yVfbkoKIxgcWL/eWMeLslxwLmfWCAcePJBVM/gvUazjpfNlpkyJUvTZpEtTZh0
ppWjdp7K+MON/aSgosJLRIdIkzqUGnd0uXKCoYqZOhJ6ArYYIRSLezj+in1mHpzY
muAAXsvb/ezve5wmFiY2JVg2MK0OU/hRGTPtLEWWpsU38mw4VPaYA5ayFw9bYoo2
b/UswMaI2m4WGdU7ezq8GMvSbbllEAA36xCyXaPh1y6sevRyV1SP8PLCE+enD4fh
vbNBymvW7D8nAnDWfUMD+bsOYWnDg2vBBbgOLy52NsvR1e6/wrrzZzLI9j9n9KrS
F1BYmL2MnvX2MOZPu8RBVSwuv7lT3/7rUYdyQ9qo7cc8NB6h3f6Aaqw76ZqOSbGb
gDm3yMCjxS5SAH4ZND8FxsWKOnG1kJDUPLnsG6SLYEunGQp9Jvyv/qeCwmP4EjvA
VLxQqHsLUiBXQWLYvGoAEcMPtEy7OrKQBRCwDCRPlDWIudT4ObgJe1XHzaGJOGxj
dimGuiTiO+AHD+Aa+ODtucgcciNZ39142awFWn8z+JRH7e65dFldT2XtV7N+4DKk
54nVU6a4PEe32ZcneHJO
=LNOZ
-----END PGP SIGNATURE-----
--Apple-Mail=_4FD06163-4F1C-4554-BEEB-6A134E9E4A6C--
|
