Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.51 as permitted sender)
	client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f51.google.com; 
MIME-Version: 1.0
Date: Wed, 13 Mar 2013 14:15:22 -0700
Message-ID: <CAAS2fgSxZw56TNzGEBeTpykJcc=4WKixG2LEd3EnY46z7wy1VA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] On fork awareness Was: 0.8.1 ideas
Precedence: list

On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins <andyparkins@gmail.com> wrote=
:
> 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 transaction=
s

The development of two chains was maximally bad because the state was
irreconcilable without the manual intervention. The only reason you're
saying that it was only the false confirms that were bad is because
manual intervention resolved the worse badness. :)  A whole bunch of
people spending coins that can only exist in the different exclusive
chains would have been very bad indeed.

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

Not reliably, you will only hear of a competing chain if some of your
peers have accepted it. If your peers were all pre-0.8 or all 0.8 you
only would have heard of one chain.

Relaying non-primary chains has some obvious and subtle challenges=E2=80=94
Obviously you need some way of preventing it from being a DOS vector,
but thats not a fundamental issue=E2=80=94 you could rate limit by only
relaying chains which are close to the current best in sum difficulty=E2=80=
=94
just a software engineering one.

A more subtle issue is it that it's not in a node's self-interest to
tell peers about a chain it thinks is invalid: it wants its peers on
_its_ view of the consensus, not some other one.  Though perhaps this
could be addressed by only relaying headers for non-primary chains.