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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1Wcoi9-0002J9-8b
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 04:23:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
designates 74.125.82.45 as permitted sender)
client-ip=74.125.82.45; envelope-from=jgarzik@bitpay.com;
helo=mail-wg0-f45.google.com;
Received: from mail-wg0-f45.google.com ([74.125.82.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wcoi5-0001Dr-Sv
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 04:23:05 +0000
Received: by mail-wg0-f45.google.com with SMTP id l18so325255wgh.16
for <bitcoin-development@lists.sourceforge.net>;
Tue, 22 Apr 2014 21:22:55 -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:content-transfer-encoding;
bh=BBFF5eUs0cW6mYo3K4U2HghskmBJc32JMK3KTgxDo+4=;
b=cTmTs6u9UZuHNlrgE29spgW9e5RjxrjZ0yodUZXeIsPKniTkCNmZgoxicWgwo1Nzx+
yp5v7P0Uy2WaRH57bchghx9r6Oe0wYx0tlDvrs1RajZ33AuqfbmY3tRUlCsZM4lajCgH
FdcMskD5xhOw/HDeHagr+1llgO+Pe9q9IEYmSpLjSKf/8q9BbF8Q+vZ1MVVlli3CjPVx
MNK/RLaGoMy8zz0RFYLL6JIKy5Q22o0HT2hIH7oT5D4re8mkqHyEQ3DkRjqLm5FmbSe0
Xw8nmeidCf7dTqDrkf67BGiuEjY8zU08/SR0fNKMCa4bwCHpdTukhwB1rZLI1a7v/p++
zvoA==
X-Gm-Message-State: ALoCoQnTGjWRuOShl1ARIFrqAojSBPN9Ila6UvoNxv34T7RVGiiV04ev+oRUekOwEQ7DAPPbBrE5
X-Received: by 10.180.85.10 with SMTP id d10mr30181wiz.0.1398226975637; Tue,
22 Apr 2014 21:22:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.243.138 with HTTP; Tue, 22 Apr 2014 21:22:35 -0700 (PDT)
In-Reply-To: <53574581.3040004@thinlink.com>
References: <20140422213128.GB2578@savin> <53574581.3040004@thinlink.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 23 Apr 2014 00:22:35 -0400
Message-ID: <CAJHLa0M8A6xpWMm1tCBCSTT=Q4Ks6ZCCXWdX_t62-4x+9_eRZg@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
-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: 1Wcoi5-0001Dr-Sv
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double-spending unconfirmed transactions
is a lot easier than most people realise
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 04:23:05 -0000
A lot of these "should the network..." questions depend on business
rules and business models.
Even if a 0-conf double spend is possible in a given business
situation, the incentives quite often are aligned to avoid
double-spend attempts in any case. Any physical good being shipped
can "accept" the transaction, and then wait for confirmations before
shipping. Digital goods might be accepted for 0-conf payment from
users who have a good history with the merchant. The 0-conf attacker
will tend to /not/ be a regular user, and also have many other typical
markers of a fraudster.
The subset of (a) double-spend attackers making a one-time or
short-term attack on (b) a naive merchant with mistuned business rules
will tend to be very small.
On Wed, Apr 23, 2014 at 12:45 AM, Tom Harding <tomh@thinlink.com> wrote:
>
> Since no complete solution to preventing 0-confirmation respends in the
> bitcoin network has been proposed, or is likely to exist, when
> evaluating partial solutions let's ask "what kind of network does this
> move toward?"
>
> Does the solution move toward a network with simple rules, where the
> certainty that decreases from the many-confirmations state, down to 1
> confirmation, does not immediately disappear just below the time of 1
> confirmation?
>
> A network where transaction submitters consider their (final)
> transactions to be unchangeable the moment they are transmitted, and
> where the network's goal is to confirm only transactions all of whose
> UTXO's have not yet been seen in a final transaction's input, has a
> chance to be such a network. If respend attempts are broadcast widely,
> then after a time on the order of transaction propagation time (<< 1
> minute) has passed, participants have a good chance to avoid relying on
> a transaction whose funds are spent to someone else. This is both
> because after this time the network is unlikely to split on the primacy
> of one spend, and because the recipient, able to see a respend attempt,
> can withhold delivery of the good or service until confirmation.
>
> Or, does the solution move toward a network that
> - Requires participants to have knowledge of the policies of multiple
> entities, like Eligius and whoever maintains the blacklist mentioned belo=
w?
> - Requires a transaction submitter to intently monitor transactions
> and try to climb over the top of attempted respends with
> "scorched-earth" triple spends, until a random moment some time between,
> let's say, 5 and 15 minutes in the future?
> - Punts the problem to off-network solutions?
>
>
> On 4/22/2014 1:31 PM, Peter Todd wrote:
>> You may have seen my reddit post of the same title a few days ago:
>>
>> http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirm=
ed_transactions_is_a_lot/
>>
>> I've done some more experiments since, with good results. For instance
>> here's a real-world double-spend of the gambling service Lucky Bit:
>>
>> Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd=
20
>>
>> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f=
79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a=
38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca=
7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401ff=
fffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888=
ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270=
000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000
>>
>> Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce=
88582a
>>
>> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f=
79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed5=
63390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c=
476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401ff=
fffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888=
ac00000000
>>
>> The double-spend was mined by Eligius and made use of the fact that
>> Eligius blacklists transactions to a number of addresses considered to
>> be "spam" by the pool operators; affected transactions are not added to
>> the Eligus mempool at all. Lucky Bit has a real-time display of bets as
>> they are accepted; I simply watched that display to determine whether or
>> not I had lost. With Eligius at 8% and the house edge at 1.75% the
>> attack is profitable when automated. My replace-by-fee patch(1) was
>> used, although as there are only a handful of such nodes running - none
>> connected directly to Eligius from what I can determine - I submitted
>> the double-spend transactions to Eligius directly via their pushtxn
>> webform.(2)
>>
>> Of course, this is an especially difficult case, as you must send the
>> double-spend after the original transaction - normally just sending a
>> non-standard tx to Eligius first would suffice. Note how this defeats
>> Andresen's double-spend-relay patch(3) as proposed since the
>> double-spend is a non-standard transaction.
>>
>> In discussion with Lucky Bit they have added case-specific code to
>> reject transactions with known blacklisted outputs; the above
>> double-spend I preformed is no longer possible. Of course, if the
>> (reused) Lucky Bit addresses are added to that blacklist, that approach
>> isn't viable - I suggest they switch to a scheme where addresses are not
>> reused. (per-customer? rotated?) They also have added code to keep track
>> of double-spend occurances and trigger human intervention prior to
>> unacceptable losses. Longer term as with most services (e.g. Just-Dice)
>> they intend to move to off-chain transactions. They are also considering
>> implementing replace-by-fee scorched earth(4) - in their case a single
>> pool, such as Eligius, implementing it would be enough to make the
>> attack unprofitable. It may also be enough security to allow users to
>> use their deposits prior to the first confirmation in a Just-Dice style
>> off-chain implementation.
>>
>> 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
>>
>> 2) http://eligius.st/~wizkid057/newstats/pushtxn.php
>>
>> 3) https://github.com/bitcoin/bitcoin/pull/3354 and
>> https://github.com/bitcoin/bitcoin/pull/3883
>>
>> 4) https://bitcointalk.org/index.php?topic=3D251233.msg2669189#msg266918=
9
>
> -------------------------------------------------------------------------=
-----
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--=20
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
