From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D897B958 for ; Wed, 25 Jan 2017 04:03:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D59C140 for ; Wed, 25 Jan 2017 04:03:48 +0000 (UTC) Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by mx.zohomail.com with SMTPS id 1485317024391545.4686974422764; Tue, 24 Jan 2017 20:03:44 -0800 (PST) From: Johnson Lau 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: To: Tom Harding , bitcoin-dev In-Reply-To: Message-Id: <3F2FDFFC-A73B-4C0F-A7B2-8449332BE70E@xbt.hk> X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 04:03:50 -0000 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 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