From: Thomas Zander <thomas@thomaszander.se>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 28 Oct 2014 07:24:07 +0100
Message-ID: <1835049.8OJNQBmq5F@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16-3-amd64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <544EFEE8.4000000@thinlink.com>
References: <544EA3D7.2050901@thinlink.com> <544EA85E.8010400@bluematt.me>
	<544EFEE8.4000000@thinlink.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [Bitcoin-development] DS Deprecation Window
Precedence: list

On Monday 27. October 2014 19.26.48 Tom Harding wrote:
> Miner has to be very careful including a double-spend in his block -- he 
> hopes:

How does it help the zero-confirmation to not include a payment? Doesn't that 
just mean that if I send a double spend that neither of the payments will be 
made? So the thief just got an even bigger incentive to double-spent!
 

>   - that based on his measured time offset from the first spend he 
> received, at most a tiny fraction of the network will delay his block
>
>   - that not too many nodes saw an earlier spend that he didn't see, 
> which could increase that fraction
> 
>   - that most other nodes saw his tx.  Any who didn't will only learn 
> about it by receiving his block, and they will assign it the time when 
> they receive the block.  That's likely to be more than T (30 seconds) 
> after an earlier spend, so they would delay the block.

This doesn't addresses the point that Matt brought up.
Your proposal essentially has some side effects that would be disastrous to 
miners. As detailed by the other two replies on this thread.