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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Qp6DG-0000v0-Rf
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 22:16:22 +0000
Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qp6DF-0002YG-Qe for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 22:16:22 +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 3F8A62CCD
for <bitcoin-development@lists.sourceforge.net>;
Fri, 5 Aug 2011 00:16:09 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CANEZrP3kEquEvqkqGqSh0iPRqoHhKLHoNgqc+9EORLoxpL7a=g@mail.gmail.com>
References: <201108041423.14176.andyparkins@gmail.com>
<201108041922.16956.andyparkins@gmail.com>
<1312483196.3109.38.camel@Desktop666>
<201108042042.55214.andyparkins@gmail.com>
<CANEZrP3kEquEvqkqGqSh0iPRqoHhKLHoNgqc+9EORLoxpL7a=g@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
protocol="application/pgp-signature";
boundary="=-koQb+HMDBR5uLSn7qVCJ"
Date: Fri, 05 Aug 2011 00:16:13 +0200
Message-ID: <1312496173.3109.55.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: 1Qp6DF-0002YG-Qe
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 22:16:22 -0000
--=-koQb+HMDBR5uLSn7qVCJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, 2011-08-04 at 23:36 +0200, Mike Hearn wrote:
> The vending machine/detecting double spends issue was discussed by
> Satoshi in July 2010:
>=20
> https://bitcointalk.org/index.php?topic=3D423.msg3819#msg3819
>=20
> He mentioned payment processors that could "alert the transaction is bad"=
.
I stand with satoshi here. No need to add more stuff to the network
protocol, a well-connected node can easily monitor the miners(/network)
for double-spends and alert whoever may need to know that the
transaction should not be accepted. True, not everyone has the
resources to try to implement this, however the number of people who
have the resources to implement a Bitcoin storefront and not implement
this (vs those who will/do use a payment processor who handles such
things), I would think, are fairly small.
Additionally, keep in mind that many storefronts don't need to care if a
transaction confirms in 10 seconds or 1 hour. Only digital goods and
physical purchases could benefit from such speed increases.
On Fri, 2011-08-05 at 00:10 +0200, Stefan Thomas wrote:
Since nobody else has mentioned it: There is another (more pragmatic?)=20
> way to detect double spends:
>=20
> 1. Connect to lots of clients
> 2a. If they all send you the same transaction -> double spend unlikely
> 2b. If some don't send you the transaction (or send a conflicting one)=
=20
> -> double spend in progress
This is exactly what I've been suggesting this whole time.
--=-koQb+HMDBR5uLSn7qVCJ
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)
iQIcBAABAgAGBQJOOxorAAoJEBrh01BD4I5UpjUQAIvIeoHcYoqReb/H634AmxcO
3qrKdY+Ro496TdRAj2q2SWN4z99tovSY9CFe5hWFWzLndoNcR+1c4e+75rNwtuoX
cmsyT/ruyRX19BDMAj0K+HYGoczQtjj4A2UviSC/QbjibG2elFOVzddfRpz5evFp
pXFFnYHA/PxNcjN/EpHklfSDOvh+ElGxKwFozjnJypKQ+/15Yy4+Oy+tSkcab9ye
9bHvhhONegum1MMqEwXjexS0omwO3ops14PMai3Ytwyp14VEE5uHpqvPBQvCG4Jr
/c46eQDOd2UEMnzUXBzfPFwURYvp4b1YvTRA8dQYFIcMyzSdh4SmbK2LfEk+i/0r
PvUNGoVUuR5iBlVRhEDi03aZRBORZ4Bms5y1Rc7t1B2R5n6nLnDTcH1Z73WyjSci
fEWKuU0/ul8Pw+hMvo3S9+QdZIOVV8Cn9u9ZRi8pPqwH3i9rXgjm0Pky0c6I8Rdn
HZXP1U5FIj+021MF8qKEFpvKk0911UUiCTmUMRdvAfjrH/Qod3P4AVqHzvS32j42
YeWK8PZRA9ez3+pBsrBNB7xC3FaXcDZwTbxspNPi5pgqGjgZG9wgxHI4IQeyYxUF
L5xYZa1/qQzAmBvmfzBOgvTSLGt0V2Uq3bs6JqcpE9M9crmKLDM02qeggVzhOwcO
T+CvNGj4OAA58sXtw+hP
=H1YO
-----END PGP SIGNATURE-----
--=-koQb+HMDBR5uLSn7qVCJ--
|
