From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 25 Jan 2017 12:03:40 +0800
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
	<efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>
To: Tom Harding <tomh@thinlink.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <efad941b-ce3e-1c98-ca5b-51da66badc6c@thinlink.com>
Message-Id: <3F2FDFFC-A73B-4C0F-A7B2-8449332BE70E@xbt.hk>
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Precedence: list

Yes, it=E2=80=99s similar. I=E2=80=99ll quote your design if/when I =
formalise my BIP. But it seems they are not the same: yours is opt-out, =
while mine is opt-in.

However, my proposal in nowhere depends on standardness for the =
protection. It depends on the new network enforcing a new SignatureHash =
for txs with an nVersion not used in the existing network. This itself =
is a hardfork and the existing network would never accept such txs.

This is to avoid requiring any consensus changes to the existing =
network, as there is no guarantee that such softfork would be accepted =
by the existing network. If the new network wants to protect their =
users, it=E2=80=99d be trivial for them to include a SignatureHash =
hardfork like this, along with other other hardfork changes. Further =
hardforks will only require changing the network characteristic bit, but =
not the SignatureHash.

If the hardfork designers don=E2=80=99t like the fix of BIP143, there =
are many other options. The simplest one would be a trivial change to =
Satoshi=E2=80=99s SignatureHash, such as adding an extra value at the =
end of the algorithm. I just don=E2=80=99t see any technical reasons not =
to fix the O(n^2) problem altogether, if it is trivial (but not that =
trivial if the hardfork is not based on segwit)


> On 25 Jan 2017, at 02:52, Tom Harding <tomh@thinlink.com> wrote:
>=20
> 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)
>=20
> Johnson,
>=20
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.h=
tml.
>=20
> 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.
>=20
> 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.
>=20
>=20