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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up
 transaction trust
Precedence: list

> 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.