Message-ID: <53A0F2FD.7010605@thinlink.com>
Date: Tue, 17 Jun 2014 19:01:33 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>	<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
	<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
In-Reply-To: <CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
 backwards compatible proto buffer extension
Precedence: list

On 6/16/2014 8:09 AM, Daniel Rice wrote:
> What if we solved doublespends like this: If a node receives 2 
> transactions that use the same input, they can put both of them into 
> the new block as a proof of double spend, but the bitcoins are not 
> sent to the outputs of either transactions. They are instead treated 
> like a fee and given to the block solver node. This gives miners the 
> needed incentive and tools to end doublespends instead of being forced 
> to favor one transaction over the other.

Before considering a hard fork with unpredictable effects on the 
uncertainty window, it would be interesting to look at a soft fork that 
would directly target the goal of reducing the uncertainty window, like 
treating locally-detected double-spends aged > T as invalid (see earlier 
message "A statistical consensus rule for reducing 0-conf double-spend 
risk").

If anything is worth a soft fork, wouldn't reducing the double-spend 
uncertainty window by an order of magnitude be in the running?

Reducing the reasons that transactions don't get relayed, which actually 
seems to have a shot of happening pretty soon, would also make this kind 
of thing work better.