To: bitcoin-dev@lists.linuxfoundation.org
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
	<93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
	<CAAcC9ys4dH3hFzXJon7ho_TP3YwOd=SB2DB0oW5-NnNY5Q19Cw@mail.gmail.com>
	<CEA70782-BE59-486E-BD79-0446A73DEDC3@xbt.hk>
	<CAAcC9ytGJUe8_va+Ft2u=1SLm=0=vTpm1QPhJekNGh-WvktW8A@mail.gmail.com>
	<7AF0AA6D-C144-4D0C-B5FC-0BC2C79C0D26@xbt.hk>
From: Tom Harding <tomh@thinlink.com>
Message-ID: <369b781f-065f-9a1d-a3d7-e98a6fe7f4f6@thinlink.com>
Date: Thu, 26 Jan 2017 07:58:23 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
	Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <7AF0AA6D-C144-4D0C-B5FC-0BC2C79C0D26@xbt.hk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Precedence: list

Even more to the point, new post- fork coins are fork-specific.  The 
longer both forks persist, the more transactions become unavoidably 
fork-specific through the mixing in of these coins.  Any attempt to 
maximize replay will become less effective with time.

The rationality of actors in this situation essentially defines the 
limited solution that is possible.  Upgraded software can create 
transactions guaranteed not to execute to one fork or the other, or that 
is not prevented from execution on either fork.  I see no downside to 
this, and the advantage is that markets can be much less chaotic.  In 
fact exchanges will be much better off if they require that post-fork 
trading, deposits and withdrawals are exclusively chain-specific, which 
will also result in well determined prices for the two currencies.

None of this precludes the possibility of further forks on either side, 
and the difficulty consideration alone suggests a likely counter-fork by 
(part of) the existing network.


On 1/26/2017 1:20 AM, Johnson Lau via bitcoin-dev wrote:
> Not to mention that mining is a random process, and the hashing power is going up and down.