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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Qp5af-0007wS-ST
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 21:36:29 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qp5ae-0001AJ-TE
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Aug 2011 21:36:29 +0000
Received: by vws2 with SMTP id 2so2580820vws.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Aug 2011 14:36:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.76.8 with SMTP id g8mr896185vdw.178.1312493783418; Thu, 04
Aug 2011 14:36:23 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.158.233 with HTTP; Thu, 4 Aug 2011 14:36:23 -0700 (PDT)
In-Reply-To: <201108042042.55214.andyparkins@gmail.com>
References: <201108041423.14176.andyparkins@gmail.com>
<201108041922.16956.andyparkins@gmail.com>
<1312483196.3109.38.camel@Desktop666>
<201108042042.55214.andyparkins@gmail.com>
Date: Thu, 4 Aug 2011 23:36:23 +0200
X-Google-Sender-Auth: YVkx5MIqx8UEyMiamv98Z4TIPQc
Message-ID: <CANEZrP3kEquEvqkqGqSh0iPRqoHhKLHoNgqc+9EORLoxpL7a=g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
1.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qp5ae-0001AJ-TE
Cc: bitcoin-development@lists.sourceforge.net
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 21:36:30 -0000
> If it's still an experiment why is there such huge objection to pretty much
> every change anyone proposes?
I don't think there are huge objections to every change. You've only
really argued about this with Matt ;)
The vending machine/detecting double spends issue was discussed by
Satoshi in July 2010:
https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
He mentioned payment processors that could "alert the transaction is bad".
Gregorys idea looks sound to me. It'd be useful, though, to have a NAK
message for transactions anyway (not propagated). It's possible to get
yourself into a situation today where you connect to nodes that refuse
to relay your transaction for some reason (perhaps your peers are
using old fee rules, or you are) but you think the transaction was
relayed. The user is left wondering why the spend didn't confirm.
If nodes sent a message saying "I refuse to process this tx because
<reason>" it'd make debugging and testing easier as well.
|
