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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1Qp3oy-00073m-5g
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 19:43:08 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-wy0-f175.google.com;
Received: from mail-wy0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qp3ov-0005dj-RV
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 19:43:08 +0000
Received: by wyg30 with SMTP id 30so2367611wyg.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 12:42:59 -0700 (PDT)
Received: by 10.216.81.2 with SMTP id l2mr1094782wee.22.1312486979552;
Thu, 04 Aug 2011 12:42:59 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id r48sm1394402weq.2.2011.08.04.12.42.57
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 04 Aug 2011 12:42:58 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 4 Aug 2011 20:42:55 +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>
<201108041922.16956.andyparkins@gmail.com>
<1312483196.3109.38.camel@Desktop666>
In-Reply-To: <1312483196.3109.38.camel@Desktop666>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201108042042.55214.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: 1Qp3ov-0005dj-RV
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 19:43:08 -0000
On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:
> But why? It results in slightly more network traffic which is exactly
> what we don't want, and it adds yet another message people have to know
> about.
"Slightly" is an understatement. It add more network traffic for every
double spend attempt. Which don't happen very often.
Also, I'm not proposing a new message, heaven forbid that we add a new
message type, I'm proposing that we do this:
enum
{
MSG_TX = 1,
MSG_BLOCK,
+ MSG_DOUBLESPEND,
};
Also, people don't "have" to know about it. And it's not "people" it's an
addition to the _one_ official client. _and_ it's backward compatible
because if they don't know about it, nothing changes... the TX gets dropped
just as it is now.
> > 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.
>
> No one cares about what the network thinks is the right transaction, its
> only what miners believe that matters.
They do care because the network as a whole is what makes the eventual
decision about which is the block-chain-to-rule-them-all. Chain forks, and
eventual reorgs are also far less disruptive when each leg of a double spend
isn't on each potential chain. "Half the network" includes half of the
miners. It's perfectly possible for half the miners to be working on one
leg, half on the other. That means it's 50/50 which leg eventually gets
confirmed.
> Even if the vending machine doesn't keep the full chain and doesn't
> accept incoming connections, its still the target node. What other
> nodes on the network think doesn't matter as long as you get the target
> to think a transaction that won't be confirmed will be. If it doesn't
> accept incoming connections you want to find nodes that do that are
> connected to your target.
Well that's true enough; but how on earth you're going to identify an IP
address of a particular vending machine that isn't accepting incoming
connections is beyond me. If it is a target it's pretty close to invisible.
> Its much easier to create than to change the network code to relay info
> on double-spend transactions.
What? It's easier to trigger massive adoption and organisation of an
inherently disorgainsed network of miners than it is to write a few lines of
code? If that's true, then the bitcoin source is even more impenetrable
than I imagine.
> > 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.
>
> No, thats not what happens now. Currently if your node gets a
> transaction which conflicts with one it already knows about, it silently
> drops it without a second thought. My point is if you actually dealt
> with such cases and made good connections, you would be able to prevent
> double spends nearly perfectly.
It's not about prevention, they are already prevented. It's about
detection. Quickly.
> > 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.
>
> No, my suggestion is not to relay the second transaction. The second
> transaction should continue to not be relayed as it currently is,
> however receiving such a transaction should trigger the node to notify
> the user that the transaction should not be accepted until it makes it
> into a block (in fact, you could already do this if you implemented a
> debug.log parser and made well-placed connections).
How is this second transaction going to end up anywhere but on a few
isolated nodes if it isn't propagated? The only way _both_ can be in a pool
is if they are both received. If they aren't both forwarded then it won't
be in most pools. If it isn't in most pools then which how is the relevant
user going to get notified?
> Bitcoin is absolutely still an experiment and no one thinks that any
> kind of future is guaranteed. This was not meant as an argument, but
If it's still an experiment why is there such huge objection to pretty much
every change anyone proposes? Bitcoin is one of the most conservative
projects I've ever seen, even for the most passive of changes. I can
understand wanting to prevent potential financial loss, but it's not like
I'm suggesting we start broadcasting private keys on the network.
> simply as "if bitcoin does end up going somewhere, it will likely be
> done like this".
When you're using it as an argument for why a suggestion is unnecessary
that's not how it sounds.
Anyway; it's fine. You don't think it's a good idea; and I suspect none of
the other official client developers will either, they don't like protocol
changes. So be it; it was only a suggestion and I'm a nobody around here.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
