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
|
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 <jgarzik@bitpay.com>) id 1Z6lFo-00035h-2e
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 19:50:08 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.218.52 as permitted sender)
client-ip=209.85.218.52; envelope-from=jgarzik@bitpay.com;
helo=mail-oi0-f52.google.com;
Received: from mail-oi0-f52.google.com ([209.85.218.52])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6lFm-0000Nm-T1
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 19:50:08 +0000
Received: by oigx81 with SMTP id x81so109589276oig.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Jun 2015 12:50:01 -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:from:date
:message-id:subject:to:cc:content-type;
bh=ASgbL8qtE/8r/Fy9CMLv9qbvLMmdfNRIr29/hDbzUM8=;
b=E48AnKBtnFJA+goaYKuGZ37IHg0eTATuIKFEe1/amBVgjN3o7l6HaVm4glRt2QCi/+
YEyoP2rAdWAjmyqHGBWMzXBPmzUlvB/aK05NaqwInb2EN64JSq2AtBmzKJDkSXqYGyT3
0pt+EsVUuPXlL83bJoNNapU/7VvxtwsIE2v8d88oHfUQ1/NgayMFe0q43SPeCbyOO8+t
IqSfhnfOFtlE5Z7Zy3gO/lzksFeMk0QkklRfOu96TY/QWWMW01FbAmgCogdLBApcF+aV
695c/w4IHWgmCs05YYkJ6elWQq4sHX19+/FWrHkGcSRlOe8dTr1vlsJ9oYj1JFOmdh+R
2rdQ==
X-Gm-Message-State: ALoCoQlomIc1OlAhCvfSN/R1KLBk3bK8zXREYgzlZ/Hl0l5+Gi0eDwNJSIjEYbzNtiw3yGvhmhr6
X-Received: by 10.60.45.104 with SMTP id l8mr22508523oem.61.1434916201304;
Sun, 21 Jun 2015 12:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Sun, 21 Jun 2015 12:49:41 -0700 (PDT)
In-Reply-To: <30AF043D-A1F8-4502-8280-EBED6063B6B6@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>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Sun, 21 Jun 2015 12:49:41 -0700
Message-ID: <CAJHLa0NJw2UA68gJq8bqLXr4ptgWC8drvvs8d3AwA+iHcmMvJQ@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=089e0149ce38762d4905190c76e1
X-Spam-Score: -0.5 (/)
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
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.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6lFm-0000Nm-T1
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 19:50:08 -0000
--089e0149ce38762d4905190c76e1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo <elombrozo@gmail.com> wrote=
:
> 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.
>
> Even more important than the specific software you=E2=80=99re using is th=
e
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods=E2=80=A6especially if they req=
uire
> 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.
>
Already done -- BitPay merchants choose their level of transaction
security. Level of confirmations is directly exposed to merchants, so that
they choose the level of risk for themselves.
Physically shipped orders and subscriptions are actually the easy cases and
are already handled. These can accept 0-conf for an initial order phase,
then have the luxury of time to wait for confirmations before shipping /
canceling a subscription.
Electronic goods instantly delivered are the toughest use case. Even
there, merchants choose their level of risk.
> 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 yo=
u
>
The system requests this information on orders yes. Merchants also collect
this info as their needs dictate.
> 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 i=
f 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.
>
Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...
--=20
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--089e0149ce38762d4905190c76e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo <span dir=
=3D"ltr"><<a href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elomb=
rozo@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:b=
reak-word"><div><div class=3D"h5"><span style=3D"color:rgb(34,34,34)">Thank=
s for asking *the* question, Jeff. We often get caught up in these philosop=
hical debates=E2=80=A6but at the end of the day we need something concrete.=
</span><br></div></div><div><br></div><div>Even more important than the spe=
cific software you=E2=80=99re using is the security policy.</div><div><br><=
/div><div>If you must accept zero confirmation transactions, there are a fe=
w concrete things you can do to reduce your exposure:</div><div><br></div><=
div>1) limit the transaction amounts for zero confirmation transactions - d=
o not accept them for very high priced goods=E2=80=A6especially if they req=
uire physical shipping.</div><div>2) limit the total amount of unconfirmed =
revenue you=E2=80=99ll tolerate at any given moment - if the amount is exce=
eded, require confirmations.</div><div>3) give merchants of subscription se=
rvices (i.e. servers, hosting, etc=E2=80=A6) the ability to shut the user o=
ut if a double-spend is detected.</div></div></blockquote><div><br></div><d=
iv>Already done -- BitPay merchants choose their level of transaction secur=
ity.=C2=A0 Level of confirmations is directly exposed to merchants, so that=
they choose the level of risk for themselves.</div><div><br></div><div>Phy=
sically shipped orders and subscriptions are actually the easy cases and ar=
e already handled.=C2=A0 These can accept 0-conf for an initial order phase=
, then have the luxury of time to wait for confirmations before shipping / =
canceling a subscription.</div><div><br></div><div>Electronic goods instant=
ly delivered are the toughest use case.=C2=A0 Even there, merchants choose =
their level of risk.</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div style=3D"word-wrap:break-word"><div>4) collect legal inf=
ormation on purchasers (or have the merchants collect this information) so =
you have someone to go after if they try to screw you</div></div></blockquo=
te><div><br></div><div>The system requests this information on orders yes.=
=C2=A0 Merchants also collect this info as their needs dictate.</div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word=
-wrap:break-word"><div>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>6) get=
insurance (although right now reasonably-priced insurance is probably pret=
ty hard to obtain since statistics are generally of little use=E2=80=A6we=
=E2=80=99re entering uncharted territory).</div><div>7) set up a warning sy=
stem and a =E2=80=9Cpanic=E2=80=9D button so that if you start to see an at=
tack you can immediately disable all zero confirmation transactions system-=
wide.</div><div>8) independently verify all inbound transactions and connec=
t to multiple network nodes=E2=80=A6check them against one another.</div></=
div></blockquote><div><br></div><div>Definitely looking at or have implemen=
ted this sort of stuff.=C2=A0 I cannot get into detail in public...</div></=
div><div><br></div>-- <br><div class=3D"gmail_signature">Jeff Garzik<br>Bit=
coin core developer and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=
=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.=
com/</a></div>
</div></div>
--089e0149ce38762d4905190c76e1--
|
