Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.182 as permitted sender)
	client-ip=209.85.217.182; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f182.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANAnSg2sUfRH0mYEir_XKUz-iOYRpdzNgM-AJ7t-H=SOa4wBig@mail.gmail.com>
References: <N1-9eAtMHauq2@Safe-mail.net>
	<CANAnSg2sUfRH0mYEir_XKUz-iOYRpdzNgM-AJ7t-H=SOa4wBig@mail.gmail.com>
Date: Tue, 5 Nov 2013 15:06:52 -0800
Message-ID: <CAAS2fgTofL7ura17KjUR5pL_fOOM=a0gdZTZ7seVMRPOPi66xw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Drak <drak@zikula.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Possible Solution To SM Attack
Precedence: list

On Tue, Nov 5, 2013 at 2:15 PM, Drak <drak@zikula.org> wrote:
> If I understand the issue properly, this seems like a pretty elegant
> solution: if two blocks are broadcast within a certain period of eachother,
> chose the lower target. That's a provable fair way of randomly choosing the
> winning block and would seem like a pretty simply patch.

uh. and so when my solution is, by chance, unusually low... I am
incentivized to hurry up and release my block because?

I've simulated non-first-block-heard strategies in the past (in the
two nearly tied miner with network latency model) and they result in
significant increase in large (e.g. >>6 block) reorgs). It's easy to
make convergence worse or to create additional perverse incentives.