summaryrefslogtreecommitdiff
path: root/ca/6e8b47287d38c428ca7a55e4d7b9325a3f4cb8
blob: 0fa198d1277c4be8270591400effe4ac0aff662c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C0242BC1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Jan 2017 07:15:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f179.google.com (mail-yb0-f179.google.com
	[209.85.213.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1278BE3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Jan 2017 07:15:15 +0000 (UTC)
Received: by mail-yb0-f179.google.com with SMTP id f67so382740ybc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 24 Jan 2017 23:15:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=OYaf/ucX5wUWizI5CS+z7ar/dbRc3d8u4viFtS+T81Q=;
	b=P2D6IkxEGciGd6Z5gtfoT9wu2p20hwppIOccGuIAVToIsU7Wp3Jae4KJgbTqFeTx4M
	0yGqitauu+sqVCXt204ATh0f2Is+0HO9nDNkXwjPMXn9KWcCLWEm4HA525GhsbaAQjEL
	U9lL6GP2dmluhQ95R2M8+jycV8trL0uBqty4QxS2110J1bwSvzsPyfc4CE8pAV9dk9V8
	2KH2cky6qs/LDzQvK/FJKDTvxsfb7B2XLxYJgMzf8psBKzAaai40daTDS4W9BdOaF1V1
	dNwaQ7wlMksmfxwdmdyyMUR5mg4ddbWf9ynf0Soz5MAilfOw5Y+rHPf6p+7aSJxSX2hF
	gDMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=OYaf/ucX5wUWizI5CS+z7ar/dbRc3d8u4viFtS+T81Q=;
	b=tfqAdzlI5UeKkfOD2vY/k/KQaWVGT+miXiw6CMDQL8JTqYJGqBIw8UFMEnEDsIYeqG
	AEhlBPr/kPqwtqm8uZlYkOCSsrV14JZLWh+09/j+p4yNqA2MMe4gMzQAXS9X12MVJcrc
	TJMCfV+6hJOrCD2Gi11SMUfTxcyT3fVOrQoHb/atWE16K2Wr3Wgbb6OnOYlGaXzvCDWx
	rRR/Oyqe9ItuPtmps6lqXGlhMkEO00GKT4568zYMA7DhXamqTwz4q3oZnpbioSh1UIHK
	Qm7G7iBtz2Z1Ems+T4+wIBFDCxrebVRYf9OGXz8CjRk1LH4U+P8or/0qPf5Pm4qJVUw/
	rNgQ==
X-Gm-Message-State: AIkVDXKMQQacR1I2+zP5LIH207tMMlhiytn/5YiCf9ARm0MU2A9wbBFA6FlBmIak9XUuaHoXj9woe9GgvVmWTg==
X-Received: by 10.37.85.70 with SMTP id j67mr22933451ybb.192.1485328515302;
	Tue, 24 Jan 2017 23:15:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 23:15:14 -0800 (PST)
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 23:15:14 -0800 (PST)
In-Reply-To: <311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
	<CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com>
	<311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 25 Jan 2017 08:15:14 +0100
Message-ID: <CAAt2M1_cQTfaDyQkaixeFB5Ubi35fSOs9Ks74WZEehtFk__B3w@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=001a113ff8588790b40546e5fe9f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	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 <bitcoin-dev@lists.linuxfoundation.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 07:15:17 -0000

--001a113ff8588790b40546e5fe9f
Content-Type: text/plain; charset=UTF-8

Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012@xbt.hk>:

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.


Read it again.

The validation algorithm would be extended so that the transaction can't be
replayed, because replaying it in the other network REQUIRES a child
transaction in the same block that is valid, a child transaction the is
unique to the network. By doing this policy change simultaneously in both
networks, old pre-signed transactions *can not be replayed by anybody but
the owner* of the coins (as he must spend them immediately in the child
transaction).

It means that as soon as spent, the UTXO sets immediately and irrevocably
diverges across the two networks. Which is the entire point, isn't it?

--001a113ff8588790b40546e5fe9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D=
"gmail_quote">Den 25 jan. 2017 08:06 skrev &quot;Johnson Lau&quot; &lt;<a h=
ref=3D"mailto:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt;:<br type=3D"attribution"=
><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>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.</=
div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Read it again.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">The validation algorithm would be extended so that the transaction can&#=
39;t be replayed, because replaying it in the other network REQUIRES a chil=
d transaction in the same block that is valid, a child transaction the is u=
nique to the network. By doing this policy change simultaneously in both ne=
tworks, old pre-signed transactions *can not be replayed by anybody but the=
 owner* of the coins (as he must spend them immediately in the child transa=
ction).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">It means t=
hat as soon as spent, the UTXO sets immediately and irrevocably diverges ac=
ross the two networks. Which is the entire point, isn&#39;t it?=C2=A0</div>=
<div class=3D"gmail_extra" dir=3D"auto"></div></div>

--001a113ff8588790b40546e5fe9f--