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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Qp1z7-0001S2-7V
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 17:45:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
designates 173.246.101.161 as permitted sender)
client-ip=173.246.101.161;
envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qp1z6-0008C1-0X for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 17:45:29 +0000
Received: from [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b] (unknown
[IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b])
by mail.bluematt.me (Postfix) with ESMTPSA id 7CF682CCD
for <bitcoin-development@lists.sourceforge.net>;
Thu, 4 Aug 2011 19:45:15 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <201108041423.14176.andyparkins@gmail.com>
References: <201108041423.14176.andyparkins@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
protocol="application/pgp-signature";
boundary="=-deiKSgTc0+0BC4IEA86B"
Date: Thu, 04 Aug 2011 19:45:17 +0200
Message-ID: <1312479917.3109.25.camel@Desktop666>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Spam-Score: -2.3 (--)
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.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Qp1z6-0008C1-0X
Subject: Re: [Bitcoin-development] Double spend detection to speed up
transaction trust
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: Thu, 04 Aug 2011 17:45:29 -0000
--=-deiKSgTc0+0BC4IEA86B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
There really is no reason to add the extra network complexity for this.
First of all (as you point out) no one buying a Ferrari will refuse to
wait an hour for the payment to confirm. If someone is attempting to
pull a similar trick on, say, a vending machine however it might make
sense. But that changes the equation. In order for these two scammers
to pull it off, some effort is required in terms of communicating the
time to send the coins and the nodes of the targets (vending machines or
whatever) must be figured out. So now its less of "make it impossible"
and more of "make it really hard to the point that it is no where near
worth the effort".
Lets simplify the scenario a bit so that one scammer can pull it off.
Send one copy of your transaction to the target node and another to
large mining operations so that the payment transaction is considered
invalid to miners and a transaction which pays you is confirmed.
If you are the vending machine, your goal is not to figure out any
transactions which are yours, but to figure out which transactions which
are yours are going to be confirmed. So, you peer with the largest
miners (a "Bitcoin backbone" or large miners and merchants has been
suggested over and over again and really hasn't happened) and modify
your client to, instead of dropping transactions which are
double-spends, keep both in memory pool and consider them both invalid
until one of them confirms.
This will work with 1, 2, or n scammers, doesn't require any additional
network messages, and offers just as good, if not better security over a
double spend message.
Additionally, in the future, when(/if) Bitcoin payment processors exist,
most merchants will rely on those, which can handle such double-spend
checks and tell a merchant a transaction is confirmed in ten seconds for
small transactions, an hour for large ones, or anywhere in between.
Such payment processors could also mine or have contracts with large
miners which allows them to influence the transactions which are to be
confirmed, allowing for even quicker confirmations and the offering of
insurance against unconfirmed transactions being invalidated.
Matt
On Thu, 2011-08-04 at 14:23 +0100, Andy Parkins wrote:
> Hello,
>=20
> Here's a scenario (it's contrived to make the players easy to identify, m=
ore=20
> likely this would be low value automated vendors):
>=20
> Two scammers get together to buy two Ferraris using only one set of BTC. =
They=20
> travel to opposite ends of the world to two car dealerships that accept=
=20
> bitcoins without waiting for confirmations. They are in contact by mobil=
e. =20
> They each buy the car and come to pay. At exactly the same moment, they =
both=20
> spend the same coins. They both walk away with a car.
>=20
> The current solution is the recommendation that vendors wait for six=20
> confirmations before releasing goods. That's a long time though; more th=
an=20
> most would be willing to wait.
>=20
> Some points:
> - The bitcoin network is essentially honest
> - If a block chain fork happens, the transactions that are orphaned get =
added
> to the pending transaction list again, meaning ...
> - A valid transaction will _eventually_ make it into the (longest) block
> chain.
> - Actual distribution time for a transaction through the network is in t=
he
> order of seconds not minutes
> - A double spend attempt has to enter the network near simulateously at
> different places, otherwise the second spend will be rejected instantl=
y by
> the whole network.
>=20
> New transactions propagate through the network if they are found to be va=
lid. =20
> If they aren't valid, they are silently dropped. In the event of a doubl=
e=20
> spend attempt one of those transactions goes to (say) half the network, t=
he=20
> other goes to the other half. Whichever one reaches a node first is seen=
as=20
> the real one, the second being seen as invalid. One or other of these wi=
ll=20
> therefore end up in the "longest" chain; but there is no way to know whic=
h.
>=20
> Here's my proposal then: when a node drops a transaction, it should not b=
e=20
> silent. It should be broadcast just as it always was going to be had it =
been=20
> valid. Only it is broadcast with a new "inv" type, let's say=20
> "MSG_DOUBLESPEND" instead of "MSG_TX".
>=20
> Now run the Ferrari test again. The vendor sees the transaction that pay=
s for=20
> the car appear near instantly (within the propagation time of the network=
). A=20
> short while later they also see a MSG_DOUBLESPEND of the same coins that =
they=20
> have just accepted. They can then operate whatever policy they want: wai=
t for=20
> six, ten, twenty confirmations. Call the police. Whatever. Miners can =
also=20
> significantly lower the priority of any transactions that get flagged in =
this=20
> way.
>=20
> When there isn't a double spend attempt message within the network propag=
ation=20
> time, they can be sure that their transaction is the one that miners are=
=20
> working on, and they'll eventually get their money. In other words, they=
can=20
> accept the payment on zero confirmations.
>=20
> At first I was concerned that this would make it possible to DOS a=20
> transaction, but of course it doesn't -- the transaction has to be intern=
ally-
> valid to result in a MSG_DOUBLESPEND, meaning it can only be DOSed by som=
eone=20
> with the appropriate private keys.
>=20
>=20
>=20
> Andy
--=-deiKSgTc0+0BC4IEA86B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJOOtqlAAoJEBrh01BD4I5USrAP/juLC1NSQ8xeUcUP/QREs1i9
qayQ0b0l4ALE/5cVp2I/1k+g/S/V6wK9icgSIjJJWJAsvpgBIWhgcntMZKUqW0xh
uRpkTrBefccMeDZiDDJxNk6K3qJz2sDM4+J1Akz7CaoToZ4x3YNnMxNDbDvaOyCo
qfBqWqpDQ1AtN3aDt86c8cy7324dtgFw3LPQ72tQdRPTAmafQl8ZwAJRaQZDSh2B
GO8jJbmeZqahhlmJCFu9TSRRJecK44sPppJq5My2d1gCmxMKNZ1YGstMsLrcp8A4
9llnRrc6Tp7SZfcZ84JwMldtAg27PTaSQ0U4lJOEmJeHO0PNLDm69p8G/Aaft5A3
baWs7CpszSlwkW4MmDf/SYww1dVfW8DrXWCX4y3TS9BXSNUF41wqBso/NzQlpwZL
oz7otD7/13PDptz/H5m5RaQy7m+CT+aTxaeN0lzCuyNoqMF0cribt8nqQj43klr6
3I4XZ4EUJZa25TKM3QT3DtHIA2/Fvnvs0v2CC3gr48y4XriDMQt4f6sX5u3gOy8Q
XEzzvcl1rV9kYqO9mpwMrav21YSsT8wWvZ/cUcZWJWHIUrzU1rlejn5TpHVxz349
bFGoAWpo6bcWVmsrIFBw/GS7h3HYVWOwreoVKMFdQ0HXe1HVjJGa00h0vYMMDZ98
2JzpHGYWyNdeEZdIPnVV
=kulV
-----END PGP SIGNATURE-----
--=-deiKSgTc0+0BC4IEA86B--
|
