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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
Return-Path: <mats@blockchain.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B41F6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 10:03:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com
[209.85.128.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 863ADE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 10:03:09 +0000 (UTC)
Received: by mail-wr0-f175.google.com with SMTP id q66so13865723wrb.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 02:03:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockchain.com; s=google;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=y7TDixF2uiFcJ8r2VPRsIvO99Z7L+gEkGFsej0EiJxo=;
b=jH2gLdJasS4ZBHsNPkWo1DVjPktE5kjVzjIdZ9iswlxhbeO0H2RJUa9AaEvav/xHg7
qbjTZ9qYIMjNmBqKfJIsvszpX296B1j2QnoIjYKeWdSb7RLWTy+LiIMT46h3+rP0LP1i
qz5wPPSaSc+oQ3crdbjcJIrv+VQEBxQCgV+rc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=y7TDixF2uiFcJ8r2VPRsIvO99Z7L+gEkGFsej0EiJxo=;
b=Rv+cTZ3VAlfFDWiCahxE2ha6/MWXyWGXDHqgKkpRWNljUHChCd3D4KnSAlHLF1pxMO
GX7gBYE1BizhqEMvHhT2b+etpFCX/QKPoPud1muDOVV/N/5Y903tjNE/8H3dW0sMRrgI
GqKq17IfmKUl6+0oI4VshQCCUTwmaT3Z7/Faw9wvIsSTfhdEVHsrwPu+ps9h2wEGZiCq
P4qM5X+2tuh910p+2SK/nw3WIi6tTh4zRxAv3UQ2LXpEOY9owFcEvq8YFm3j/Vc2sja6
Zz5Zi5cKv/9ZxQtAOWN2lPsrPER2B3EmFZrrwz5aokEITRmxxGIfnvkU2GqZrw35enE6
55Xg==
X-Gm-Message-State: AJaThX78Et+epGgYxe35nrDtpz3DWc9/tymnndtA5h+RWQoix25w9rwq
MriypVOzRQmFOHNa0hkB9o7bBA==
X-Google-Smtp-Source: AGs4zMYxRCviXs5D+KPPQy3oDbh8SrIT5X5LQdO7+PV68XTjyQcDqcY0W4sgmmXrPZGk6VYnRUYjGA==
X-Received: by 10.223.129.41 with SMTP id 38mr7243743wrm.57.1510567388134;
Mon, 13 Nov 2017 02:03:08 -0800 (PST)
Received: from [192.168.2.105] (p5089FF1E.dip0.t-ipconnect.de. [80.137.255.30])
by smtp.gmail.com with ESMTPSA id f6sm4400381wre.66.2017.11.13.02.03.06
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 13 Nov 2017 02:03:06 -0800 (PST)
From: Mats Jerratsch <mats@blockchain.com>
Message-Id: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 13 Nov 2017 10:03:04 +0000
In-Reply-To: <CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com>
<CAAUaCyii2U5VBLS+Va+F3h4Hka0OWDnFFmjtsvyaaD4TKVzV3Q@mail.gmail.com>
<CAAUaCyiZ0bmWZLZc-yDvVHupzbdRR=Kdq4P8VkWqpU1L3G-u3A@mail.gmail.com>
<C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.com>
<CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com>
<45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl>
<CAAUaCygeOxAK=EpzfWndx6uVvVO9B+=YTs1m-jHa3BFp82jA4w@mail.gmail.com>
<95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl>
<CAAUaCyg_PGT0F=RHfX89T54j-vuyz5wcbXaYoikJv95WKgsNPg@mail.gmail.com>
<55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl>
<CAAUaCyhncyCt_ao9i0=33LswDOkCf6o-+36zrGxKWD+WranmZw@mail.gmail.com>
<46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl>
<CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
<3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com>
<CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 13 Nov 2017 13:54:53 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
Forks
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: Mon, 13 Nov 2017 10:03:10 -0000
--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230
Content-Type: multipart/alternative;
boundary="Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56"
--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> OK, so nForkId 0 is exactly the "valid on all chains" specifier I was =
asking about, cool. And your LN example (and nLockTime txs in general) =
illustrate why it's preferable to implement a generic replay protection =
scheme like yours in advance, rather than before each fork: all ad hoc =
RP schemes I know of break old txs on one of the chains, even when =
that's not desirable - ie, they offer no wildcard like nForkId 0.
Exactly!
> One comment on your LN example: users would have to take note that =
nForkId 0 txs would be valid not only on future forks, but on past forks =
too. Eg, if BCH had been deployed with nForkId 2, then a user setting =
up BTC LN txs now with nForkId 0 would have to be aware that those txs =
would be valid for BCH too. Of course the user could avoid this by =
funding from a BTC-only address, but it is a potential minor pitfall of =
nForkId 0. (Which I don't see any clean way around.)
This is actually incorrect. There are two transactions involved in LN. =
The funding transaction, which opens a payment channel, and a commitment =
transaction, which closes the channel when broadcasted to the network =
(the cooperative closing transaction can be considered a commitment =
transaction in a loose sense).
Now you want to protect the funding transaction, as otherwise you would =
be subject to a replay-attack on all *past* forks. So you will set =
`nForkId>=3D1` for the funding transaction, making this payment channel =
non-existent on any *past* forks. However, if during the lifetime of the =
payment channel another fork happens, the payment channel exists for =
both tokens. So for the commitment transaction, you will have =
`nForkId=3D0`, making it valid on both of these chains. While this =
`nForkId` is valid on all chains, the parent transaction it tries to =
spend (the funding transaction) does only exist on two chains, the =
original one you created the channel for and the one that forked away.
--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D"">OK, so nForkId 0 is exactly the =
"valid on all chains" specifier I was asking about, cool. And your =
LN example (and nLockTime txs in general) illustrate why it's preferable =
to implement a generic replay protection scheme like yours <i =
class=3D"">in advance</i>, rather than before each fork: all ad hoc RP =
schemes I know of break old txs on one of the chains, even when that's =
not desirable - ie, they offer no wildcard like nForkId =
0.</div></div></blockquote><div><br =
class=3D""></div><div>Exactly!</div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"">One comment on your LN example: users would have to take note =
that nForkId 0 txs would be valid not only on future forks, but on <i =
class=3D"">past</i> forks too. Eg, if BCH had been deployed with =
nForkId 2, then a user setting up BTC LN txs now with nForkId 0 would =
have to be aware that those txs would be valid for BCH too. Of =
course the user could avoid this by funding from a BTC-only address, but =
it is a potential minor pitfall of nForkId 0. (Which I don't see =
any clean way around.)</div></div>
</div></blockquote></div><br class=3D""><div class=3D"">This is actually =
incorrect. There are two transactions involved in LN. The funding =
transaction, which opens a payment channel, and a commitment =
transaction, which closes the channel when broadcasted to the network =
(the cooperative closing transaction can be considered a commitment =
transaction in a loose sense). </div><div class=3D""><br =
class=3D""></div><div class=3D"">Now you want to protect the funding =
transaction, as otherwise you would be subject to a replay-attack on all =
*past* forks. So you will set `nForkId>=3D1` for the funding =
transaction, making this payment channel non-existent on any *past* =
forks. However, if during the lifetime of the payment channel another =
fork happens, the payment channel exists for both tokens. So for the =
commitment transaction, you will have `nForkId=3D0`, making it valid on =
both of these chains. While this `nForkId` is valid on all chains, the =
parent transaction it tries to spend (the funding transaction) does only =
exist on two chains, the original one you created the channel for and =
the one that forked away. </div></body></html>=
--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56--
--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJaCW3ZAAoJEAYZmwZ/PsbKmQ4P/RwgMvqhJKjID7qt+q1TELZZ
bqvoym9dzIdo37lT0DUmS8TNRxAU3liBkgCdBLUQXd9ktVIHGUsGr/rPZnQfD9pk
yHK9AdhBO14QPH2wHqzDb5W3YTUAsMWb4K/YCsMqZX2miAvdRCw8fLnITrnHxe2c
nWj2t4SAAPplDRTuhMljJ843KzR0CCdOQo7YPE5KM9VWihil56+wrGHGFNvVl789
cgJhPvgpt3WeMlIF95tYJhew0af3xtHmo1Z8KJYF/8zJb4BpnrAh6aKxyKxws4ut
E0bRNUtUB1hj17w1Rv82vM6KW5hKj0JmtSdcOJqe0gasAnqS81hCiEQQC4B8vMab
jtaF/fKS6wAEPc0RRRTEzvkwv6BQIJ6lNuohR7YEiwBUGcrtZVQ5ZVtdINrNSei1
r4B5/PGaQDYKqyoVoSLb/6NbzEiPdfJt/1tnMEI77HQSbFoibl25rDhBRHKlKjSl
8wdun06teL0wniOPNkoStrNqywTLGspw7PZZeWWsgocD9mAPPNsAeA1QPyKxphs5
AaDLPzC43+/IBpCwGCMrLbWRwdxb2FizAX/peKzXbCLmrFw24Yxo95+KR10vMBu3
YIWodo1nFd9XrWbHTmvl6Kfrlg76UN3MeclyclaTUXBAIkN7GjKDC+wv8a8z46AZ
YzfAUC9jJ8pf/yvoitdv
=84BJ
-----END PGP SIGNATURE-----
--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230--
|
