diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2017-01-25 12:03:40 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-01-25 04:03:49 +0000 |
| commit | afcd8f2387571cc4828248d9c10db5fb828699a4 (patch) | |
| tree | 3f2da32d80a854f0b5c265a7c76de973ea3f426c | |
| parent | cc0531b64ff12bea20cc261709ff2636ef1c0413 (diff) | |
| download | pi-bitcoindev-afcd8f2387571cc4828248d9c10db5fb828699a4.tar.gz pi-bitcoindev-afcd8f2387571cc4828248d9c10db5fb828699a4.zip | |
Re: [bitcoin-dev] Anti-transaction replay in a hardfork
| -rw-r--r-- | 37/de34c1bb419ccee292812cbce8d73b18461963 | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/37/de34c1bb419ccee292812cbce8d73b18461963 b/37/de34c1bb419ccee292812cbce8d73b18461963 new file mode 100644 index 000000000..ea7874c58 --- /dev/null +++ b/37/de34c1bb419ccee292812cbce8d73b18461963 @@ -0,0 +1,106 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D897B958 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <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> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 + + + |