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
|
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 <btcdev@quinnharris.me>) id 1UeaiA-0006U6-G4
for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 00:45:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of quinnharris.me
designates 67.223.164.214 as permitted sender)
client-ip=67.223.164.214; envelope-from=btcdev@quinnharris.me;
helo=fza.durangomail.com;
Received: from fza.durangomail.com ([67.223.164.214])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Ueai8-0000qB-T4 for bitcoin-development@lists.sourceforge.net;
Tue, 21 May 2013 00:45:54 +0000
Received: from localhost (localhost [127.0.0.1])
by fza.durangomail.com (Postfix) with ESMTP id 856831EAFDD
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 18:45:46 -0600 (MDT)
X-Virus-Scanned: amavisd-new at fza.durangomail.com
Received: from fza.durangomail.com ([127.0.0.1])
by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id s2gzEo6YoMAF
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 18:45:30 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
by fza.durangomail.com (Postfix) with ESMTP id D2D821EAFFF
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 18:45:30 -0600 (MDT)
X-Virus-Scanned: amavisd-new at fza.durangomail.com
Received: from fza.durangomail.com ([127.0.0.1])
by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id UaN9XUJ_RseP
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 18:45:30 -0600 (MDT)
Received: from [192.168.1.74] (172-3-184-238.lightspeed.sntcca.sbcglobal.net
[172.3.184.238])
by fza.durangomail.com (Postfix) with ESMTPSA id 57F261EAFDD
for <bitcoin-development@lists.sourceforge.net>;
Mon, 20 May 2013 18:45:30 -0600 (MDT)
Message-ID: <519AC3A8.1020306@quinnharris.me>
Date: Mon, 20 May 2013 18:45:28 -0600
From: Quinn Harris <btcdev@quinnharris.me>
User-Agent: Mozilla/5.0 (X11; Linux i686;
rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Ueai8-0000qB-T4
Subject: [Bitcoin-development] Double Spend Notification
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: Tue, 21 May 2013 00:45:54 -0000
The current BitCoin implementation is subject to relatively easy double
spend attack for 0 confirmation payments. Yet 0 confirmation payments
are needed for typical in person transactions like most purchases at a
local business.
Notably, it is easy to transmit two transactions from the same output at
the same time to different sets of nodes on the network by using two
instances of bitcoind with same wallet file and a spend on each daemon
initiated by RPC by some easy to implement code. If the first attempt
to pay the merchant doesn't go through because they received the "wrong"
transaction it could be quickly followed up with another initiated spend
from a different output switching which daemon sends the transaction the
merchant is expecting. This means an unsophisticated attacker can
reliably get away with this attack and it would be worth while for small
transactions. Given this, I would be reluctant to trust 0 confirmation
transactions at all though I think many do in practice. Someone could
write and publish a special daemon to execute this attack further
reducing the cost.
Right now a node will drop any second spend of the same output in the
memory pool. After the first transaction has propagated through the
network issuing a second double spend transaction isn't likely to be
seen by a significant number of miners as most nodes especially non
miner nodes will drop this transaction. Today, it is necessary to
transmit both transactions on the network nearly simultaneously to
reliably get away with this simple attack. If in this case, the
receiving end is quickly notified of the double spend this attack
becomes more more difficult to get away with.
If the second transaction is relayed instead of being dropped to notify
the receiving party of the double spend, most miners will receive both
transactions and it is possible that some or even many of the miners
would replace the first transaction with the second if it has a higher
fee as it would be in their short term interest. This can happen some
time after the first transaction has propagated through the network so
the receiving end wouldn't get a timely notification of the double
spend. Depending on the choices of the miners, this approach to double
spend notification could exacerbate the very problem it was attempting
to fix compared to the current implementation. While miners might
continue to drop the second spends, the easy availability of the second
spends would increase the short term reward for changing this policy.
This problem can be fixed if instead of sending the second transaction a
new double spend message is sent with proof of the double spend but not
the complete transactions. This would allow the receiving end to be
quickly notified of a double spend while in no way increase the chance
over the current implementation that a double spend would be successful.
The proof of the double spend would include the scriptSig (input) from
the original transactions and the hashes from the "simplified"
transaction used by OP_CHECKSIG of the scriptPubKey (output) but not the
entire transaction. This is the hash computed by the SignatureHash
function in script.cpp. The double spend notification message should
contain proofs of both signed transaction spending the same output
ordered by hash to produce a canonical proof for a specific two
transactions. To reduce DOS potential, the proof should not be relayed
unless one of the original transactions has been received to ensure
there is some commitment to the block chain and different double spend
proofs of the same output should not be relayed. The forwarding of
transactions should remain exactly the same as it is now where the
second transaction is dropped but a double spend message is transmitted
if appropriate.
The existing block chain needs to be checked to make sure the proof of
double spend couldn't have been derived from the block chain and a
single spend in the memory pool. This could happen if there was already
an identical transaction in the block chain. This would typically only
happen if someone was paying someone else the same amount they had
before and neither side changed addresses. In this case double spend
detection wouldn't be reliable as it could be generated by anyone, but
both the sending and receiving client could detect this situation and
warn the user.
It would still be possible for an attacker to send the second
transaction directly to powerful miners but this is a distinctly less
viable attack than the current double spend attack.
I would expect this double spend notification implementation to make
double spends more costly than they are worth for most cases today that
0 confirmation acceptance is needed. That said over time this provision
might become less effective. As the reward for each block mined
decreases, transactions fees will become a more significant part of the
mining reward accordingly increasing the incentive to replace
transactions with higher fees. Today most BitCoin participants have a
high expectation of significant future appreciation of BitCoins and
recognize anything that brings into question the integrity of the system
is likely to reduce that future value so they have a long term self
interest to keep up the impression of integrity. As BitCoin becomes
more establish this incentive will decrease.
On the other hand, non mining nodes have no incentive to replace by
fee. The continued increased capital costs of mining would likely
increase the proportion of non mining nodes typically run by those with
an incentive to assure integrity of the network such as merchants. But
increasing transaction volume is likely to increase node costs which
would push out non mining nodes with lower incentive more than mining
nodes. Accordingly increasing block size would have a tendency to
reduce the effectiveness of double spend notification. The primary
point is there are multiple counteracting forces that make predicting
the future effectiveness of double spend notification uncertain.
I don't believe this necessary warrants conceding that we can not
provide any protection from non trusted 0 confirmations transaction as a
replace by fee implementation would do. But it would still be important
to work towards more robust solutions notably various forms of 3rd party
trust. This could be tamper resistant devices trusted to not duplicate
spends, 3rd party certificates with proof the transaction was spent by
the holder of the certificate or multi signature transactions on the
block chain that must be signed by a trusted 3rd party to spend. I
would expect it would take significantly longer for the companies and
technologies to be built to implement this on a wide scale than adding
double spend proof messages to the current implementation. In addition,
there will likely always be some use cases where a 3rd party
(centralization) is not viable.
Should a BIP and pull request implementing a double spend notification
as described be accepted?
- Quinn
|
