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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YPZDV-0007T2-KY
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 16:17:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174; envelope-from=natanael.l@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPZDT-0002Yi-MG
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 16:17:13 +0000
Received: by mail-wi0-f174.google.com with SMTP id em10so12106231wid.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Feb 2015 08:17:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.76.178 with SMTP id l18mr12649506wiw.36.1424621825715;
Sun, 22 Feb 2015 08:17:05 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 22 Feb 2015 08:17:05 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 22 Feb 2015 08:17:05 -0800 (PST)
In-Reply-To: <54E9FD05.3000807@localhost.local>
References: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
<20150222123428.GA6570@savin.petertodd.org>
<CAAt2M18fPgYOsfdebmU1Tk6ATnndPBn0k2PN-4fUJs1iTBTqnQ@mail.gmail.com>
<2953246.T2DHreG0Tu@crushinator> <54E9FD05.3000807@localhost.local>
Date: Sun, 22 Feb 2015 17:17:05 +0100
Message-ID: <CAAt2M19u6AsULxUov9Z6JP+ByJRCaj3s5hQfe3TT-zfKgCuyxA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Justus Ranvier <justusranvier@riseup.net>
Content-Type: multipart/alternative; boundary=f46d04389387dc75b6050faf9d56
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(natanael.l[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
X-Headers-End: 1YPZDT-0002Yi-MG
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] alternate proposal opt-in miner takes
double-spend (Re: replace-by-fee v0.10.0rc4)
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, 22 Feb 2015 16:17:13 -0000
--f46d04389387dc75b6050faf9d56
Content-Type: text/plain; charset=UTF-8
Den 22 feb 2015 17:00 skrev "Justus Ranvier" <justusranvier@riseup.net>:
>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> > This happened to one of the merchants at the Bitcoin 2013
> > conference in San Jose. They sold some T-shirts and accepted
> > zero-confirmation transactions. The transactions depended on other
> > unconfirmed transactions, which never confirmed, so this merchant
> > never got their money.
> >
> > I keep telling people not to accept transactions with zero
> > confirmations, but no one listens.
>
> A better solution is to track the failure rate of zero confirmation
> transactions, and adjust prices accordingly to cover the expected loss.
>
> This is what every merchant *already does* since no payment method has
> a 0% fraud rate.
>
> Even physical cash has a probability of being counterfeit, and the
> prices you pay for things at a convenience store already have that
> risk priced in.
>
> The idea that zero confirmation transactions require a 100% guarantee
> is a strawman, especially since there exists no number of
> confirmations the actually produce a 100% irreversibility guarantee.
The problem with this approach is that it is worthless as a predictor. We
aren't dealing with traffic safety and road design - we are dealing with
adaptive attackers and malicious miners and pools.
Anything which does not invalidate blocks carrying doublespends WILL allow
malicious miners and pools to conspire with thieves to steal money. The
probability of being hit will then be (their proliferation in your business
area) * (their fraction of the mining power).
That might seem to give small numbers for most sets of reasonable
assumptions. But the problem is that's only an average, and the people
being hit might have small profit margins - one successful attack can place
hundreds of merchants in red numbers and force them to shut down.
You should never expose yourself to attacks which you can't defend against
and which can be fatal. In particular not if there's nothing in the
environment that is capable of limiting the size or numbers of any attacks.
And there's no such thing today in Bitcoin.
This is why I sketched out the multisignature notary approach, and why some
decided to extend that approach with collateral (NoRiskWallet) to further
reduce trust in the notary. This is the single most practical approach I
know of today to achieve ACTUAL SECURITY for unconfirmed transactions.
Don't like it? See if you can do better!
Just don't rely on zero-confirmation transactions!
--f46d04389387dc75b6050faf9d56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 22 feb 2015 17:00 skrev "Justus Ranvier" <<a href=3D"mailt=
o:justusranvier@riseup.net">justusranvier@riseup.net</a>>:<br>
><br>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:<br>
> > This happened to one of the merchants at the Bitcoin 2013<br>
> > conference in San Jose. They sold some T-shirts and accepted<br>
> > zero-confirmation transactions. The transactions depended on othe=
r<br>
> > unconfirmed transactions, which never confirmed, so this merchant=
<br>
> > never got their money.<br>
> ><br>
> > I keep telling people not to accept transactions with zero<br>
> > confirmations, but no one listens.<br>
><br>
> A better solution is to track the failure rate of zero confirmation<br=
>
> transactions, and adjust prices accordingly to cover the expected loss=
.<br>
><br>
> This is what every merchant *already does* since no payment method has=
<br>
> a 0% fraud rate.<br>
><br>
> Even physical cash has a probability of being counterfeit, and the<br>
> prices you pay for things at a convenience store already have that<br>
> risk priced in.<br>
><br>
> The idea that zero confirmation transactions require a 100% guarantee<=
br>
> is a strawman, especially since there exists no number of<br>
> confirmations the actually produce a 100% irreversibility guarantee.</=
p>
<p dir=3D"ltr">The problem with this approach is that it is worthless as a =
predictor. We aren't dealing with traffic safety and road design - we a=
re dealing with adaptive attackers and malicious miners and pools. </p>
<p dir=3D"ltr">Anything which does not invalidate blocks carrying doublespe=
nds WILL allow malicious miners and pools to conspire with thieves to steal=
money. The probability of being hit will then be (their proliferation in y=
our business area) * (their fraction of the mining power). </p>
<p dir=3D"ltr">That might seem to give small numbers for most sets of reaso=
nable assumptions. But the problem is that's only an average, and the p=
eople being hit might have small profit margins - one successful attack can=
place hundreds of merchants in red numbers and force them to shut down. </=
p>
<p dir=3D"ltr">You should never expose yourself to attacks which you can=
9;t defend against and which can be fatal. In particular not if there's=
nothing in the environment that is capable of limiting the size or numbers=
of any attacks. And there's no such thing today in Bitcoin. </p>
<p dir=3D"ltr">This is why I sketched out the multisignature notary approac=
h, and why some decided to extend that approach with collateral (NoRiskWall=
et) to further reduce trust in the notary. This is the single most practica=
l approach I know of today to achieve ACTUAL SECURITY for unconfirmed trans=
actions.</p>
<p dir=3D"ltr">Don't like it? See if you can do better! </p>
<p dir=3D"ltr">Just don't rely on zero-confirmation transactions! </p>
--f46d04389387dc75b6050faf9d56--
|
