summaryrefslogtreecommitdiff
path: root/18/38b79c6854f44db2c9c8112c70c8773b748bce
blob: ee00fc902ce115bc4f722aaa1f7585198d6b1581 (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
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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
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 9019F989
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 11:28:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
	[209.85.128.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 996988A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 11:28:11 +0000 (UTC)
Received: by mail-wr0-f170.google.com with SMTP id o88so8302425wrb.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 03:28:11 -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=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=;
	b=BjCIxp4IQf62XS9WrA7GPt16ShNFLKc9f4X3syMLOhypo22t7PhmQSlAq3yJs7HS8B
	i/oSxaNLDGWo4gk+ScCm9a2Mrm0dcBdvkjDpuW+nLdRo3SCOw2qBOXTr0KEC1Dm4MqJE
	tm9T93CgDtp4zlDsScx30ReV+mL2gGBOCA9Ks=
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=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=;
	b=kORUHW57m9p91LIM8+2ioU+Uw28PoqjfNtDRjo3Lq0V8YS9kLL3Uwldv/06AvkgD0B
	ZfObp/V0za4rJrllBVZw10OInDRFAlk2q9poUEBuKQhBvhitHUhzG3N3bVN+oC8Ml7q/
	Y1U3j3K8JWRBt1z/nHFWc5x/M1B+wBSXHPjZ36llav54fsaSMvlt0xTZoSJdYaCUAm9x
	7pygPxZWqgrrjcgqaJgA0sk/sSwP9qZft47K+CK5TPw1P4ogVhh2wW1zmMDOBJK1O9eV
	yQP8dr0OPNcRrYnv9FpN3290zWHcGpwzCP3vluKHJwzhR/aA1ukA2QiXWjatSIFsLmsD
	OFvQ==
X-Gm-Message-State: AJaThX4qN/IboksB+973RYmZAcAJEeDHW4IJeWZrAsXBfsHC1jHtWr6j
	Cs/VMYnhSjNhicxnkcRiQN2jBQ==
X-Google-Smtp-Source: ABhQp+TglJDieVoott1dRZu+nPWTnCzkmCadP32TWGBnSKHkBMfn+9T8fQZYtttSxgYm9fEt5fVK0Q==
X-Received: by 10.223.165.67 with SMTP id j3mr2927945wrb.271.1510313290103;
	Fri, 10 Nov 2017 03:28:10 -0800 (PST)
Received: from [10.2.1.168] ([212.161.45.230])
	by smtp.gmail.com with ESMTPSA id
	o8sm24795483wrc.10.2017.11.10.03.28.08
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 10 Nov 2017 03:28:08 -0800 (PST)
From: Mats Jerratsch <mats@blockchain.com>
Message-Id: <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 10 Nov 2017 11:28:06 +0000
In-Reply-To: <CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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>
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: Fri, 10 Nov 2017 23:42:47 +0000
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: Fri, 10 Nov 2017 11:28:12 -0000


--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543"


--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I guess I wasn't clear on the wildcard, `nForkId=3D0`

This proposal puts Bitcoin at `nForkId=3D1`, with the purpose of having =
`nForkId=3D0` valid on *all* future forks. This means you can create a =
`nLockTime` transaction, delete the private key and still be assured to =
not lose potential future tokens.

In theory `nForkId=3D0` could be used for an address too, the sending =
wallet should display a warning message about unknown side effects =
though. This address would be future-safe, and you can put it into a =
safe-deposit box (even though I see little reason to back up an =
_address_. You would always back up a _private key_, which translates =
into funds on any fork.)

Furthermore, `nForkId=3D0` can be used for L2 applications. Let's say =
Alice and Bob open a payment channel. One week later, project X decides =
to fork the network into a new token, implementing a custom way of =
providing strong two-way replay protection. The protocol Alice and Bob =
use for the payment channel has not implemented this new form of replay =
protection. Alice and Bob now have to make a choice:

(1) Ignore this new token. This comes with an evaluation of how much =
this new token could be worth in the future. They will continue normal =
channel operation, knowing that their funds on the other branch will be =
locked up until eternity. When they close their payment channel, the =
closing transaction will get rejected from the other network, because =
it's not following the format for replay protected transactions.

(2) Close the payment channel before the fork. The transaction, which =
closes the payment channel has to be mined before the fork, potentially =
paying a higher-than-normal fee.

With this proposal implemented, there are two additional choices

(3) Create the commitment transactions with `nForkId=3D0`. This ensures =
that when the channel gets closed, funds on other chains are released =
accordingly. This also means that after the fork, payments on the =
channel move both, the original token and the new token. Potentially, =
Alice and Bob want to wait before further transacting on the channel, to =
see if the token has substantial value. If it has, they can *then* close =
the channel and open a new channel again. (Note: The funding transaction =
can use a specific `nForkId`, preventing you from locking up multiple =
coins when funding the channel, but you can choose to settle with =
`nForkId=3D0` to not lock up future coins)

(4) Make the protocol aware of different `nForkId`. After the fork, the =
participants can chose to *only* close the payment channel on the new =
token, making the payment channel Bitcoin-only again. This is the =
preferred option, as it means no disruption to the original network.

> I like the idea of specifying the fork in bech32 [0]. On the other =
hand, the standard already has a human readable part. Perhaps the human =
readable part can be used as the fork id?

I was considering this too. On the other hand, it's only _human =
readable_ because thy bytes used currently encode 'bc'. For future =
forks, this would just be two random letters than, but potentially =
acceptable.


--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543
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""><span style=3D"font-size: 15px;" class=3D"">I guess I wasn't =
clear on the wildcard, `nForkId=3D0`</span><div style=3D"font-size: =
15px;" class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">This proposal puts Bitcoin at `nForkId=3D1`, with the purpose =
of having `nForkId=3D0` valid on *all* future forks. This means you can =
create a `nLockTime` transaction, delete the private key and still be =
assured to not lose potential future tokens.</div><div style=3D"font-size:=
 15px;" class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">In theory `nForkId=3D0` could be used for an address too, the =
sending wallet should display a warning message about unknown side =
effects though. This address would be future-safe, and you can put it =
into a safe-deposit box (even though I see little reason to back up an =
_address_. You would always back up a _private key_, which translates =
into funds on any fork.)</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">Furthermore, `nForkId=3D0` can be used for L2 applications. =
Let's say Alice and Bob open a payment channel. One week later, project =
X decides to fork the network into a new token, implementing a custom =
way of providing strong two-way replay protection. The protocol Alice =
and Bob use for the payment channel has not implemented this new form of =
replay protection. Alice and Bob now have to make a choice:</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">(1) Ignore this new token. This =
comes with an evaluation of how much this new token could be worth in =
the future. They will continue normal channel operation, knowing that =
their funds on the other branch will be locked up until eternity. When =
they close their payment channel, the closing transaction will get =
rejected from the other network, because it's not following the format =
for replay protected transactions.</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">(2) Close the payment channel before the fork. The =
transaction, which closes the payment channel has to be mined before the =
fork, potentially paying a higher-than-normal fee.</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">With this proposal implemented, =
there are two additional choices</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">(3) Create the commitment transactions with `nForkId=3D0`. =
This ensures that when the channel gets closed, funds on other chains =
are released accordingly. This also means that after the fork, payments =
on the channel move both, the original token and the new token. =
Potentially, Alice and Bob want to wait before further transacting on =
the channel, to see if the token has substantial value. If it has, they =
can *then* close the channel and open a new channel again. (Note: The =
funding transaction can use a specific `nForkId`, preventing you from =
locking up multiple coins when funding the channel, but you can choose =
to settle with `nForkId=3D0` to not lock up future coins)</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">(4) Make the protocol aware of =
different `nForkId`. After the fork, the participants can chose to =
*only* close the payment channel on the new token, making the payment =
channel Bitcoin-only again. This is the preferred option, as it means no =
disruption to the original network.</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">&gt; I like the idea of specifying the fork in bech32 [0]. On =
the other hand, the standard already has a human readable part. Perhaps =
the human readable part can be used as the fork id?</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">I was considering this too. On the =
other hand, it's only _human readable_ because thy bytes used currently =
encode 'bc'. For future forks, this would just be two random letters =
than, but potentially acceptable.&nbsp;</div><div style=3D"font-size: =
15px;" class=3D""><br class=3D""></div></body></html>=

--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543--

--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66
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

iQIcBAEBCgAGBQJaBY1HAAoJEAYZmwZ/PsbKcFsQAM1O0c2lrlCqaTrUug05ZKZr
KeLla73/NMBPbMgVnIriwKGijQBJ/UW76/TAWVGLOYx6C4TxtUnf75r/LsRUCEcF
lX4GtMVurzHWQNOjUNjYXh1vzAGedlN+G34wUI6VbBmdr8eco//KBJqWNCNV/F29
GHFiPtoI5x43LvJa8AeFO7htaiQAhyu3PfTNFZk9BO3xNUUK8nDN5cPvd/1cWEYl
asumhh8FZOKyAmbduuoMlReAWxfdtRHVIHT49wkooUN5kjqohtjry9lePYm/UHfk
yEYQ4YAyY1key0Q5u8DnLUR/8l1hHLWttEoOayg/+m+HPsJsOG36cORzDfdsihDP
XjMfyS1ze5xfDOusrxI5EOSQ51ikNqud2Mp52vFaO8zWL+q/y6S7UjA+fXT72WAS
9TPSYzrD4cct03pW7zEKTwVr9EtjJk4B9kl39a2EapXzQm9Onqybyw9ulm1oNWoz
TaEsfmRfs4RPfFCEcuPpgtlH8azYGbomQ+0ZBfd3Wa1iMhqMYABNX7JJ1ZaWz9zY
uGk5gEDiyNO1xJrJVuPVEpEInwUJqslq1dsIiib4MqZTdhFJ3biX32dre47Yrtpk
ltuIoA1ai5qdY6vuYsVpTnsGjmE3QSOzDAVWWN4vEf4iqUB882XpaiFUymccD+fQ
Wy+G9+SFc12Ndy6K5ATG
=pIiO
-----END PGP SIGNATURE-----

--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66--