Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 13264BC0 for ; Wed, 25 Jan 2017 07:06:09 +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 5E36DE3 for ; Wed, 25 Jan 2017 07:06:07 +0000 (UTC) Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by mx.zohomail.com with SMTPS id 1485327963372401.4201404595159; Tue, 24 Jan 2017 23:06:03 -0800 (PST) From: Johnson Lau Message-Id: <311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 25 Jan 2017 15:05:59 +0800 In-Reply-To: To: Natanael References: X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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 Cc: bitcoin-dev 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 07:06:09 -0000 --Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What you describe is not a fix of replay attack. By confirming the same = tx in both network, the tx has been already replayed. Their child txs do = not matter. > On 25 Jan 2017, at 09:22, Natanael wrote: >=20 >=20 >=20 > Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" = >: >=20 >=20 > B. For transactions created before this proposal is made, they are not = protected from anti-replay. The new fork has to accept these = transactions, as there is no guarantee that the existing fork would = survive nor maintain any value. People made time-locked transactions in = anticipation that they would be accepted later. In order to maximise the = value of such transactions, the only way is to make them accepted by any = potential hardforks. >=20 > This can be fixed.=20 >=20 > Make old-format transactions valid *only when paired with a fork-only = follow-up transaction* which is spending at least one (or all) of the = outputs of the old-format transaction.=20 >=20 > (Yes, I know this introduces new statefulness into the block = validation logic. Unfortunately it is necessary for maximal fork safety. = It can be disabled at a later time if ever deemed no longer necessary.) >=20 > Meanwhile, the old network SHOULD soft-fork in an identical rule with = a follow-up transaction format incompatible with the fork.=20 >=20 > This means that old transactions can not be replayed across = forks/networks, because they're not valid when stand-alone. It also = means that all wallet clients either needs to be updated OR paired with = software that intercepts generated transactions, and automatically = generates the correct follow-up transaction for it (old network only).=20= >=20 > The rules should be that old-format transactions can't reference = new-format transactions, even if only a softfork change differ between = the formats. This prevents an unnecessary amount of transactions pairs = generated by old wallets. Thus they can spend old outputs, but not spend = new ones.=20 >=20 >=20 --Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
What you describe is not a fix of replay = attack. By confirming the same tx in both network, the tx has been = already replayed. Their child txs do not matter.

On = 25 Jan 2017, at 09:22, Natanael <natanael.l@gmail.com> wrote:



Den 24 jan. 2017 = 15:33 skrev "Johnson Lau via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>:


B. For transactions created before this = proposal is made, they are not protected from anti-replay. The new fork = has to accept these transactions, as there is no guarantee that the = existing fork would survive nor maintain any value. People made = time-locked transactions in anticipation that they would be accepted = later. In order to maximise the value of such transactions, the only way = is to make them accepted by any potential hardforks.

This can be = fixed. 

Make old-format transactions valid *only when = paired with a fork-only follow-up transaction* which is spending at = least one (or all) of the outputs of the old-format = transaction. 

(Yes, I know this = introduces new statefulness into the block validation logic. = Unfortunately it is necessary for maximal fork safety. It can be = disabled at a later time if ever deemed no longer necessary.)

Meanwhile, the old network SHOULD soft-fork in an identical = rule with a follow-up transaction format incompatible with the = fork. 

This means that old transactions can not be = replayed across forks/networks, because they're not valid when = stand-alone. It also means that all wallet clients either needs to be = updated OR paired with software that intercepts generated transactions, = and automatically generates the correct follow-up transaction for it = (old network only). 

The rules should be that = old-format transactions can't reference new-format transactions, even if = only a softfork change differ between the formats. This prevents an = unnecessary amount of transactions pairs generated by old wallets. Thus = they can spend old outputs, but not spend new ones. 



= --Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4--