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
|
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 <mh.in.england@gmail.com>) id 1Wd2hj-0007Rw-7C
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:19:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd2hh-0001My-5l
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:19:35 +0000
Received: by mail-ob0-f175.google.com with SMTP id wp4so1537380obc.6
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 12:19:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.176.9 with SMTP id ce9mr8959437oec.55.1398280765144; Wed,
23 Apr 2014 12:19:25 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 12:19:24 -0700 (PDT)
In-Reply-To: <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
Date: Wed, 23 Apr 2014 21:19:24 +0200
X-Google-Sender-Auth: aPQh7JPIIkK8EPhpHSl_H_118K4
Message-ID: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e0118226c4d88ea04f7ba9c07
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Wd2hh-0001My-5l
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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: Wed, 23 Apr 2014 19:19:35 -0000
--089e0118226c4d88ea04f7ba9c07
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> Hm? I didn't think this is at all what they did. What they claim to
> do is to prioritize transactions in their mempool from people who pay
> them
>
That's the definition of a Finney attack, right? A tx is broadcast and
nodes normally take the first one they saw, allowing you to measure
propagation and use double spend alerts to get pretty good confidence,
pretty quick. A Finney attacker doesn't do that and includes a double
spend, so the one in the mempool gets overridden.
I mean, I hope that's the definition of a Finney attack, given that I
coined the term :)
> I think we have very clear evidence that the Bitcoin community doesn't
> care if miners reorder transactions in their mempool to profitable
> ends: In https://bitcointalk.org/index.php?topic=327767.0 it's
> demonstrated that GHash.IO, currently the largest publicly identified
> pool was used to rip off Betcoin dice via double-spends.
>
Yes, very disappointing. Though I'd hope that if this sort of thing was
sustained over months and merchants started dropping Bitcoin as a result,
miners would pay more attention.
Right now I suspect miners don't pay attention to anything other than
hardware builds though.
Yes, Bitcoin is imperfect at stopping double spends today. It can certainly
be improved! There are plenty of oft-discussed measures like double spend
alerts and discouraging Finney-attack blocks as was debated extensively in
2011. This thread is just a third such proposal.
More importantly, it's possible to deploy technological approaches to
> make zero-conf very secure against reversal: Things like performing
> multi-sig with a anti-double-spending system
>
These sorts of proposals are all just ways of saying block chains kind of
suck and we should go back to using trusted third parties.
That may well be how the Bitcoin experiment ends, but I think we all agree
here that block chains and decentralised consensus are quite spiffy and we
should try hard to make them work as well as possible before just shrugging
and say "find a trusted third party". Otherwise why not just go back to
using MasterCard? Any TTP that enforces anti double spending rules will be
a lot more centralised than miners, given the difficulty of finding them,
their need for a strong brand/reputation, and the difficulty of getting
everyone to agree on them.
Not to mention that this solution makes Bitcoin sound like a joke currency.
It's a super duper low fee totally decentralised financial system .....
unless you want to buy something in, you know, a shop. And walk out. Then
you need to sign up with this company that looks suspiciously like a bank,
and pay their fees, and yeah there's like 3 to pick from. Totally
decentralised!
> Doubly so because a 'nasty' party with non-trivial hash-power can
> doublespend their own transactions
>
If a miner is vertically integrated and defrauding merchants themselves,
with no service component, pretty quickly people would talk to each other,
notice this pattern and stop trading with them, making their coins rather
useless. Also if their real identity is ever revealed they could be liable
and there'd be a lot of people wanting to sue them.
So I think the ability to resell double spending to lots of different
people around the world seems important to practicality.
--089e0118226c4d88ea04f7ba9c07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</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"><div class=3D"">Hm? I didn't think this =
is at all what they did. =C2=A0What they claim to<br></div>
do is to prioritize transactions in their mempool from people who pay<br>
them<br></blockquote><div><br></div><div>That's the definition of a Fin=
ney attack, right? A tx is broadcast and nodes normally take the first one =
they saw, allowing you to measure propagation and use double spend alerts t=
o get pretty good confidence, pretty quick. A Finney attacker doesn't d=
o that and includes a double spend, so the one in the mempool gets overridd=
en.</div>
<div><br></div><div>I mean, I hope that's the definition of a Finney at=
tack, given that I coined the term :)</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
I think we have very clear evidence that the Bitcoin community doesn't<=
br>
care if miners reorder transactions in their mempool to profitable<br>
ends: In <a href=3D"https://bitcointalk.org/index.php?topic=3D327767.0" tar=
get=3D"_blank">https://bitcointalk.org/index.php?topic=3D327767.0</a> it=
9;s<br>
demonstrated that GHash.IO, currently the largest publicly identified<br>
pool was used to rip off Betcoin dice via double-spends.<br></blockquote><d=
iv><br></div><div>Yes, very disappointing. Though I'd hope that if this=
sort of thing was sustained over months and merchants started dropping Bit=
coin as a result, miners would pay more attention.</div>
<div><br></div><div>Right now I suspect miners don't pay attention to a=
nything other than hardware builds though.</div><div><br></div><div>Yes, Bi=
tcoin is imperfect at stopping double spends today. It can certainly be imp=
roved! There are plenty of oft-discussed measures like double spend alerts =
and discouraging Finney-attack blocks as was debated extensively in 2011. T=
his thread is just a third such proposal.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">More importantly, it's po=
ssible to deploy technological approaches to<br>
make zero-conf very secure against reversal: Things like performing<br>
multi-sig with a anti-double-spending system<br></blockquote><div><br></div=
><div>These sorts of proposals are all just ways of saying block chains kin=
d of suck and we should go back to using trusted third parties.=C2=A0</div>
<div><br></div><div>That may well be how the Bitcoin experiment ends, but I=
think we all agree here that block chains and decentralised consensus are =
quite spiffy and we should try hard to make them work as well as possible b=
efore just shrugging and say "find a trusted third party". Otherw=
ise why not just go back to using MasterCard? Any TTP that enforces anti do=
uble spending rules will be a lot more centralised than miners, given the d=
ifficulty of finding them, their need for a strong brand/reputation, and th=
e difficulty of getting everyone to agree on them.</div>
<div><br></div><div>Not to mention that this solution makes Bitcoin sound l=
ike a joke currency. It's a super duper low fee totally decentralised f=
inancial system ..... unless you want to buy something in, you know, a shop=
. And walk out. Then you need to sign up with this company that looks suspi=
ciously like a bank, and pay their fees, and yeah there's like 3 to pic=
k from. Totally decentralised!</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">Doubly so because a 'nasty' party with non-trivial =
hash-power can<br></div>
doublespend their own transactions<br></blockquote><div><br></div><div>If a=
miner is vertically integrated and defrauding merchants themselves, with n=
o service component, pretty quickly people would talk to each other, notice=
this pattern and stop trading with them, making their coins rather useless=
. Also if their real identity is ever revealed they could be liable and the=
re'd be a lot of people wanting to sue them.=C2=A0</div>
<div><br></div><div>So I think the ability to resell double spending to lot=
s of different people around the world seems important to practicality.</di=
v></div></div></div>
--089e0118226c4d88ea04f7ba9c07--
|
