To: bitcoin-dev@lists.linuxfoundation.org, Johnson Lau <jl2012@xbt.hk>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
From: Tom Harding <tomh@thinlink.com>
Message-ID: <efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>
Date: Tue, 24 Jan 2017 10:52:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
	Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Precedence: list

On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
> 9. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is set, the masked version is used to
> determine whether a transaction should be mined or relayed (policy change)

Johnson,

Your proposal supports 8 opt-out bits compatible with may earlier
description:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.

If the existing network really wants to play along, it should execute a
soft fork as soon as possible to support its own hard-fork opt-out bit
("network characteristic bit").  It is totally inadequate for a new
network to rely on non-standardness in the existing network to prevent
replay there.  Instead, in the absence of a supported opt-out bit in the
existing network, a responsible new network would allow something that
is invalid in the existing network, for transactions where replay to the
existing network is undesirable.

It is an overreach for your BIP to suggest specific changes to be
included in the new network, such as the specific O(n^2) fix you
suggest.  This is a matter for the new network itself.