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
|
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 <andyparkins@gmail.com>) id 1Qp2Yv-0003Hm-Jz
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 18:22:29 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qp2Yu-00013y-RO
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 18:22:29 +0000
Received: by wwf26 with SMTP id 26so1989209wwf.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 11:22:22 -0700 (PDT)
Received: by 10.227.160.78 with SMTP id m14mr993615wbx.80.1312482142615;
Thu, 04 Aug 2011 11:22:22 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id gd1sm1682851wbb.10.2011.08.04.11.22.19
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 04 Aug 2011 11:22:20 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 4 Aug 2011 19:22:16 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <201108041423.14176.andyparkins@gmail.com>
<1312479917.3109.25.camel@Desktop666>
In-Reply-To: <1312479917.3109.25.camel@Desktop666>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201108041922.16956.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
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
X-Headers-End: 1Qp2Yu-00013y-RO
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 18:22:29 -0000
On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> There really is no reason to add the extra network complexity for this.
It's hardly complex. It's exactly as it is now, with exactly the messages
there are now, but with an extra type added to the inventory list. A
transaction _already_ propagates using inv messages with MSG_TX, is it
really so "complex" to add MSG_DOUBLESPEND to the enum? What's more it's
backward compatible because clients that don't understand MSG_DOUBLESPEND
will ignore the inv ending up exactly where we are now.
> 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
Vending machine, newspaper salesman, ice creams, a beer. The list of small
vendors is endless. I picked Ferrari's out of the air.
> 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".
I think you've missed the point. Double spend transactions that enters the
network at two reasonably evenly connected points are each only seen by half
the network, since the first one locks out the second from propagation.
> 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.
There is no "target" node. There is only a vending machine listening for
transactions. It's unlikely that vending machines will even have incoming
connections enabled. They certainly won't be keeping a full copy of the
block chain or be mining.
> 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
It is a little bit. Your job is _first_ to figure out which are yours;
then, as you say, to see which are going to be confirmed. Well: once you've
seen a transaction on the net you know it's going to be confirmed... unless
a matching double spend transaction was accepted by the next miner to
generate a block.
> 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
It hasn't happened, and yet it seems to be that this non-existant thing is
your solution to the problem.
> 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.
Well that's what happens now. But that doesn't help the poor sap who's just
handed over some goods. I want it so that small businesses can use the
client to give them practical answers instead of this "0/unconfirmed" stuff
which requires understanding of the system.
> 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.
I'm not really trying to prevent double spends -- bitcoin _already_ prevents
double spends. Also: the only difference between your suggestion (don't
drop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a
single number in the inv. I really don't get the objection.
> Additionally, in the future, when(/if) Bitcoin payment processors exist,
"In the future" is all well and good. What if there is no future because
bitcoin is still too difficult for average joe to use?
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
