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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QoxtV-0005k5-U2
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 13:23:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QoxtV-0003BT-1w
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 13:23:25 +0000
Received: by wwf26 with SMTP id 26so1710773wwf.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 06:23:18 -0700 (PDT)
Received: by 10.216.154.144 with SMTP id h16mr610009wek.104.1312464198859;
Thu, 04 Aug 2011 06:23:18 -0700 (PDT)
Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178])
by mx.google.com with ESMTPS id r48sm1191087weq.26.2011.08.04.06.23.15
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 04 Aug 2011 06:23:16 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Date: Thu, 4 Aug 2011 14:23:10 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4338600.LmtXrNMV4W";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201108041423.14176.andyparkins@gmail.com>
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(andyparkins[at]gmail.com)
-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: 1QoxtV-0003BT-1w
Subject: [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 13:23:26 -0000
--nextPart4338600.LmtXrNMV4W
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello,
Here's a scenario (it's contrived to make the players easy to identify, mor=
e=20
likely this would be low value automated vendors):
Two scammers get together to buy two Ferraris using only one set of BTC. T=
hey=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 mobile.=
=20
They each buy the car and come to pay. At exactly the same moment, they bo=
th=20
spend the same coins. They both walk away with a car.
The current solution is the recommendation that vendors wait for six=20
confirmations before releasing goods. That's a long time though; more than=
=20
most would be willing to wait.
Some points:
- The bitcoin network is essentially honest
- If a block chain fork happens, the transactions that are orphaned get ad=
ded
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 the
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 instantly =
by
the whole network.
New transactions propagate through the network if they are found to be vali=
d. =20
If they aren't valid, they are silently dropped. In the event of a double=
=20
spend attempt one of those transactions goes to (say) half the network, the=
=20
other goes to the other half. Whichever one reaches a node first is seen a=
s=20
the real one, the second being seen as invalid. One or other of these will=
=20
therefore end up in the "longest" chain; but there is no way to know which.
Here's my proposal then: when a node drops a transaction, it should not be=
=20
silent. It should be broadcast just as it always was going to be had it be=
en=20
valid. Only it is broadcast with a new "inv" type, let's say=20
"MSG_DOUBLESPEND" instead of "MSG_TX".
Now run the Ferrari test again. The vendor sees the transaction that pays =
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 th=
ey=20
have just accepted. They can then operate whatever policy they want: wait =
for=20
six, ten, twenty confirmations. Call the police. Whatever. Miners can al=
so=20
significantly lower the priority of any transactions that get flagged in th=
is=20
way.
When there isn't a double spend attempt message within the network propagat=
ion=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 c=
an=20
accept the payment on zero confirmations.
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 internal=
ly-
valid to result in a MSG_DOUBLESPEND, meaning it can only be DOSed by someo=
ne=20
with the appropriate private keys.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart4338600.LmtXrNMV4W
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk46nT4ACgkQwQJ9gE9xL21F4wCcCYwiEdHYl8P2gvgEXYBmm+rh
VyEAoMUMcrjCDRxMrIRQgN9hPWYyU0qL
=KKPK
-----END PGP SIGNATURE-----
--nextPart4338600.LmtXrNMV4W--
|
