Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.170 as permitted sender)
	client-ip=74.125.82.170; envelope-from=andyparkins@gmail.com;
	helo=mail-we0-f170.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 13 Mar 2013 21:06:44 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-686-pae; KDE/4.8.4; i686; ; )
References: <201303131256.30144.luke@dashjr.org>
In-Reply-To: <201303131256.30144.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201303132106.45334.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] 0.8.1 ideas
Precedence: list

On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> Here's a simple proposal to start discussion from...

It seems to me that the biggest failure was not the development of two 
chains, but the assurance to users (by the client) that their transactions 
were confirmed.

Is it possible to change the definition of "6 confirmations" so that it's 
something like: "six confirmations clear of any other chain".  While there 
are two competing chains, it's possible that one will go pop at any moment.  
That makes the confirmation count of any transaction on one of those chains, 
zero.

It doesn't seem impossible that clients could be made far more permissive 
about acknowledging the existence of blockchains that they wouldn't 
necessarily accept themselves (if the proof of work was valid) and warning 
the users that it's going on.


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com