summaryrefslogtreecommitdiff
path: root/83/8c7da278dac1f245e82db6a5a1234906dd35e5
blob: 310a8b6d4ac06f9b6285659d3514e1b318a39911 (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
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z6ajR-0006hB-BA
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 08:36:01 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.175 as permitted sender)
	client-ip=209.85.192.175; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f175.google.com; 
Received: from mail-pd0-f175.google.com ([209.85.192.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z6ajQ-00063F-63
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 08:36:01 +0000
Received: by pdbci14 with SMTP id ci14so60037778pdb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 21 Jun 2015 01:35:54 -0700 (PDT)
X-Received: by 10.66.218.6 with SMTP id pc6mr47810128pac.20.1434875754401;
	Sun, 21 Jun 2015 01:35:54 -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
	qw13sm16255552pab.14.2015.06.21.01.35.52
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sun, 21 Jun 2015 01:35:53 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_6681557F-11C9-4FA2-B540-1DAC041FA45F";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <30AF043D-A1F8-4502-8280-EBED6063B6B6@gmail.com>
Date: Sun, 21 Jun 2015 01:35:50 -0700
Message-Id: <E97A66D4-E62C-498A-9FF8-27F70FD4EBA5@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>
	<70534C5D-8834-42B5-B495-FD9975E8FCF4@gmail.com>
	<CAJHLa0NkQqypvU=yANCScs3hKhTyM53rt3aNW=QRh-HmBT4-Hg@mail.gmail.com>
	<30AF043D-A1F8-4502-8280-EBED6063B6B6@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
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: 1Z6ajQ-00063F-63
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.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 08:36:01 -0000


--Apple-Mail=_6681557F-11C9-4FA2-B540-1DAC041FA45F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E492F3A3-265A-4CAD-88B3-03BB53AA9A27"


--Apple-Mail=_E492F3A3-265A-4CAD-88B3-03BB53AA9A27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>=20
>=20
>> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik@bitpay.com =
<mailto:jgarzik@bitpay.com>> wrote:
>>=20
>> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
>>  but we NEED to be applying some kind of pressure on the merchant end =
to upgrade their stuff to be more resilient
>>=20
>> Can you be specific?  What precise technical steps would you have =
BitPay and Coinbase do?  We upgrade our stuff to... what exactly?
>>=20
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/ <https://bitpay.com/>
> Thanks for asking *the* question, Jeff. We often get caught up in =
these philosophical debates=E2=80=A6but at the end of the day we need =
something concrete.
>=20
> Even more important than the specific software you=E2=80=99re using is =
the security policy.
>=20
> If you must accept zero confirmation transactions, there are a few =
concrete things you can do to reduce your exposure:
>=20
> 1) limit the transaction amounts for zero confirmation transactions - =
do not accept them for very high priced goods=E2=80=A6especially if they =
require physical shipping.
> 2) limit the total amount of unconfirmed revenue you=E2=80=99ll =
tolerate at any given moment - if the amount is exceeded, require =
confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, =
etc=E2=80=A6) the ability to shut the user out if a double-spend is =
detected.
> 4) collect legal information on purchasers (or have the merchants =
collect this information) so you have someone to go after if they try to =
screw you
> 5) create a risk profile for users=E2=80=A6and flag suspicious =
behavior (i.e. someone trying to purchase a bunch of stuff that totally =
doesn=E2=80=99t fit into their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is =
probably pretty hard to obtain since statistics are generally of little =
use=E2=80=A6we=E2=80=99re entering uncharted territory).
> 7) set up a warning system and a =E2=80=9Cpanic=E2=80=9D button so =
that if you start to see an attack you can immediately disable all zero =
confirmation transactions system-wide.
> 8) independently verify all inbound transactions and connect to =
multiple network nodes=E2=80=A6check them against one another.
>=20
>=20
> As for software tools to accomplish these things, we can talk about =
that offline :)
>=20
>=20
> - Eric Lombrozo
>=20
>=20
>=20
>=20

I should also point out that pretty much all of these suggestions =
(except for maybe 8) would apply to ANY payment system=E2=80=A6they are =
NOT specific to Bitcoin whatsoever. Any serious payment processor should =
have these sorts of policies engrained as part of company culture=E2=80=A6=
or else one day (probably not too long from now) you=E2=80=99ll be out =
of business. The mere suggestion that changing relay policy would pose =
significant threats to the bottom line of a payment processor is about =
the height of amateurishness, IMHO.


- Eric Lombrozo

--Apple-Mail=_E492F3A3-265A-4CAD-88B3-03BB53AA9A27
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 21, 2015, at 12:42 AM, Eric Lombrozo &lt;<a =
href=3D"mailto:elombrozo@gmail.com" class=3D"">elombrozo@gmail.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><meta=
 http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" =
class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space;" class=3D""><br =
class=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 20, 2015, at 11:45 PM, Jeff Garzik &lt;<a =
href=3D"mailto:jgarzik@bitpay.com" class=3D"">jgarzik@bitpay.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo =
<span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:elombrozo@gmail.com" =
target=3D"_blank" class=3D"">elombrozo@gmail.com</a>&gt;</span> =
wrote:<br class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&nbsp;but we NEED =
to be applying some kind of pressure on the merchant end to upgrade =
their stuff to be more resilient<br class=3D""></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">Can you be =
specific?&nbsp; What precise technical steps would you have BitPay and =
Coinbase do?&nbsp; We upgrade our stuff to... what =
exactly?</div></div><div class=3D""><br class=3D""></div>-- <br =
class=3D""><div class=3D"gmail_signature">Jeff Garzik<br =
class=3D"">Bitcoin core developer and open source evangelist<br =
class=3D"">BitPay, Inc. &nbsp; &nbsp; &nbsp;<a =
href=3D"https://bitpay.com/" target=3D"_blank" =
class=3D"">https://bitpay.com/</a></div>
</div></div>
</div></blockquote></div><br class=3D""><div class=3D"">Thanks for =
asking *the* question, Jeff. We often get caught up in these =
philosophical debates=E2=80=A6but at the end of the day we need =
something concrete.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Even more important than the specific software you=E2=80=99re =
using is the security policy.</div><div class=3D""><br =
class=3D""></div><div class=3D"">If you must accept zero confirmation =
transactions, there are a few concrete things you can do to reduce your =
exposure:</div><div class=3D""><br class=3D""></div><div class=3D"">1) =
limit the transaction amounts for zero confirmation transactions - do =
not accept them for very high priced goods=E2=80=A6especially if they =
require physical shipping.</div><div class=3D"">2) limit the total =
amount of unconfirmed revenue you=E2=80=99ll tolerate at any given =
moment - if the amount is exceeded, require confirmations.</div><div =
class=3D"">3) give merchants of subscription services (i.e. servers, =
hosting, etc=E2=80=A6) the ability to shut the user out if a =
double-spend is detected.</div><div class=3D"">4) collect legal =
information on purchasers (or have the merchants collect this =
information) so you have someone to go after if they try to screw =
you</div><div class=3D"">5) create a risk profile for users=E2=80=A6and =
flag suspicious behavior (i.e. someone trying to purchase a bunch of =
stuff that totally doesn=E2=80=99t fit into their purchasing =
habits).</div><div class=3D"">6) get insurance (although right now =
reasonably-priced insurance is probably pretty hard to obtain since =
statistics are generally of little use=E2=80=A6we=E2=80=99re entering =
uncharted territory).</div><div class=3D"">7) set up a warning system =
and a =E2=80=9Cpanic=E2=80=9D button so that if you start to see an =
attack you can immediately disable all zero confirmation transactions =
system-wide.</div><div class=3D"">8) independently verify all inbound =
transactions and connect to multiple network nodes=E2=80=A6check them =
against one another.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">As for software tools to =
accomplish these things, we can talk about that offline :)</div><div =
class=3D""><br class=3D""></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><div =
class=3D""><br class=3D""></div></div></div></blockquote></div><br =
class=3D""><div class=3D"">I should also point out that pretty much all =
of these suggestions (except for maybe 8) would apply to ANY payment =
system=E2=80=A6they are NOT specific to Bitcoin whatsoever. Any serious =
payment processor should have these sorts of policies engrained as part =
of company culture=E2=80=A6or else one day (probably not too long from =
now) you=E2=80=99ll be out of business. The mere suggestion that =
changing relay policy would pose significant threats to the bottom line =
of a payment processor is about the height of amateurishness, =
IMHO.</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">- Eric Lombrozo</div></body></html>=

--Apple-Mail=_E492F3A3-265A-4CAD-88B3-03BB53AA9A27--

--Apple-Mail=_6681557F-11C9-4FA2-B540-1DAC041FA45F
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

iQIcBAEBCgAGBQJVhndmAAoJEJNAI64YFENUivQQAIeaMpiZ/+tLP92XFb69OPmx
Y6+2UUhk+YnQTV1whqpy+7zzqsCl8mJUzZ9ru3PZl5yTMyaOq3dnXVwagktIp9El
m60oNXlbOf/KMlHyAqOQBTxFsLFCLE1Ukg9fKHWvxm1GPw/Tgk30RGzf5pUFtTD3
w6aU5MGFBpx2TDxOVWWgheZ0QU8/KP8vHvH22tPPqot0DViXeQJFH5htMS75wjd5
XiLdBUWUbbo/ChK7W2QMmsA5R0q+WK+6ybOq0Q+ZL0SYEOE0fiGN/++c+yKaX7WA
BzCYyaxPVU/Kza3MzGHIIN5yejilikYTOoDmE2lEKHvFyFxUd230cA0DaWxOw9t1
4bGATfDGzlOBhZbCpr0Vnyctg1+qeEcbjp/TXmmYWnu6taUdJmCv3JtDco2E77L9
LRrJA9+eOh1uh+2QQD+oFfIsTBemymwDcCZFvhb6tDdoniiun5Qluzj1RKmkWcZK
9IXM7nh0AYghTCLBDN3tyuMXZLZCqU54ijzuyj1WbxloeX4C+oruaYo+G86ZtB4Y
uV6CXc0PZ10akgVrdtJoLdWSTXwq7u+rrYgwkXb3dH/BviwFsBkkd4zkMSns4eAq
qH4p9zXMeO+CnU1Xe3ZZjYghnpNnS1PRrCp9X5s+iDZOP/OnKkite/hvmYTdyWMV
V2pg9IIfS2EZfUllfSQC
=l45g
-----END PGP SIGNATURE-----

--Apple-Mail=_6681557F-11C9-4FA2-B540-1DAC041FA45F--