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
|
Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC07B504
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Nov 2017 20:45:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com
[209.85.215.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8DC8478
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Nov 2017 20:45:46 +0000 (UTC)
Received: by mail-lf0-f51.google.com with SMTP id n69so8724415lfn.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 09 Nov 2017 12:45:46 -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=D8umICwEXu62SpWhXqJUftFMQPpJ0CJ8VB0y7ZnEUn8=;
b=OgnXSi2GoHp0TMYl7JKQ7ii6+3XV6CUVUJ4wGDTlQsQH0FnVoLDyYqjr5au5kA95CJ
xK0zZt0X61zykls0aHUsPKRA9Bxsj1PGiIGwdx7EeEKISLX1LZ/WIrSkAyddqxFGEwIe
7KwXZnFwYul+8jW4ddq42iv+DvX3jSKI5aVY2M/Gxpr67irVPUUPlM3Kr1KXbTBHsQeS
kMHPXjLxeNsGhNMWunVZxTQvRdoHFq0raY27EYd+B2nHL0jLEHJPvNz29t5zALJeo0ji
HqyyVHnfmWuBoBKqqaWbYa260ca4cmxCRkj7PBKo3fjeDJWYrM76rieaCUkQANvEen/m
R9ZA==
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=D8umICwEXu62SpWhXqJUftFMQPpJ0CJ8VB0y7ZnEUn8=;
b=qMIn5NnHcgvRH/w/HzvvVHDZk/8iUTBgTvK+1GBei4Ivqi4r81q3uTDj0OkxtTRRfN
yQ/gUBlpiJEPfuifzRNxHwLpE7vKiN48JqSHl0dEO8pYtR6C5XiNLSgDujmlflpsRR1C
FFPSnT6esFiOmrUOsyXGqI2Kq5W6p8SitCPurOoZUbOCm6lbL+jE9lMt75Sfbwyaafm9
Rq3kSBnxktjYzqm6czuCDNMNOTS/1hhFgba5lbsSSRlwDob120w1VIdg6ejlx+3GfWb+
TeVQd5hjvJ6bu2MxAtGbOpNqi6HbrVpwUkBaHLrgGKlDPZY4BVnFw33XiS/7FNbDd6ir
Xl2g==
X-Gm-Message-State: AJaThX73yWGlDm/n6PiCG0snnVY57ytv+larK/KHivDrKf1ZzqyNLqdo
3BQx++HyNCMXXHbwDdT5FgbttaKNImxinQ+oLDA=
X-Google-Smtp-Source: AGs4zMaBZuerrvINc2hNKvs17fEquugIV7qPl546g9NsrxKFP4JJkPqYYm9REmqOtuKCiRoJzpT+iaNhV4Dr3zaFmRw=
X-Received: by 10.25.217.66 with SMTP id q63mr755055lfg.176.1510260345218;
Thu, 09 Nov 2017 12:45:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.168.7 with HTTP; Thu, 9 Nov 2017 12:45:43 -0800 (PST)
Received: by 10.25.168.7 with HTTP; Thu, 9 Nov 2017 12:45:43 -0800 (PST)
In-Reply-To: <C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.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>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Thu, 9 Nov 2017 15:45:43 -0500
Message-ID: <CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com>
To: Mats Jerratsch <mats@blockchain.com>
Content-Type: multipart/alternative; boundary="94eb2c184b14652b42055d92e3e8"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,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: Thu, 09 Nov 2017 20:47:56 +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: Thu, 09 Nov 2017 20:45:47 -0000
--94eb2c184b14652b42055d92e3e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
OK, I see. On the whole this is the best replay protection solution I've
seen. In particular, I hope developers of Bech32 and other new address
formats will take a close look at incorporating a fork ID this way.
As I understand you, a private key in cold storage would (of course) remain
valid across HFs, but an *address* would be valid only for the nForkId it
was generated for. There may be cold-storage-type cases where it's
important for an address to be valid across all chains, ie, to
intentionally allow replay? But I guess this could just be a special
nForkId value, say -1?
On Nov 8, 2017 9:45 AM, "Mats Jerratsch" <mats@blockchain.com> wrote:
> Hey Jacob!
>
> > Take the specific and common case of non-upgraded wallet software.
> Suppose a HF happens, and becomes the network used by 90% of users. Will
> old wallets still default to the old nForkId (10% legacy chain)? If so,
> I'd expect a lot of accidental mis-sends on that chain.
>
> With this proposal implemented, a 'mis-send' is fundamentally impossible.
> The address contains the identifier of the token that should be sent.
>
> If anything, it's possible to 'mis-receive'.
> That is, the receiving wallet was not aware of a newer chain, and the
> receiver actually wanted to receive the newer token, but instead his wall=
et
> created an address for the old token. It is the responsibility of the
> receiver to write a correct invoice. This is the case everywhere else in
> the world too, so this seems like a reasonable trade-off.
>
> I would even argue that this should hold in a legal case, where the
> receiver cannot claim that he was expecting a payment in another token
> (contrary to how it is today, like when users send BTC to a BCH address,
> losing their funds with potentially no legal right for reimbursement). If=
I
> sent someone an invoice over 100=E2=82=AC, I cannot later proclaim that I=
actually
> expected $100.
>
> With this proposal, wallets are finally able to distinguish between
> different tokens. With this ability, I expect to see different
> implementations, some wallets which advertise staying conservative,
> following a strict ruleset, and other wallets being more experimental,
> following hashing rate or other metrics.
>
>
--94eb2c184b14652b42055d92e3e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">OK, I see.=C2=A0=C2=A0<span style=3D"font-family:sans-ser=
if">On the whole this is the best replay protection solution I've seen.=
=C2=A0 In particular, I hope developers of Bech32 and other new address for=
mats will take a close look at incorporating a fork ID this way.</span><div=
dir=3D"auto"><font face=3D"sans-serif"><br></font><div dir=3D"auto">As I u=
nderstand you, a private key in cold storage would (of course) remain valid=
across HFs, but an <i>address</i> would be valid only for the nForkId it w=
as generated for.=C2=A0 There may be cold-storage-type cases where it's=
important for an address to be valid across all chains, ie, to intentional=
ly allow replay?=C2=A0 But I guess this could just be a special nForkId val=
ue, say -1?<div dir=3D"auto"><div dir=3D"auto"><br></div></div></div></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 8, 2=
017 9:45 AM, "Mats Jerratsch" <<a href=3D"mailto:mats@blockcha=
in.com">mats@blockchain.com</a>> wrote:<br type=3D"attribution"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Hey Jacob!<br>
<br>
> Take the specific and common case of non-upgraded wallet software.=C2=
=A0 Suppose a HF happens, and becomes the network used by 90% of users.=C2=
=A0 Will old wallets still default to the old nForkId (10% legacy chain)?=
=C2=A0 If so, I'd expect a lot of accidental mis-sends on that chain.<b=
r>
<br>
With this proposal implemented, a 'mis-send' is fundamentally impos=
sible. The address contains the identifier of the token that should be sent=
.<br>
<br>
If anything, it's possible to 'mis-receive'.<br>
That is, the receiving wallet was not aware of a newer chain, and the recei=
ver actually wanted to receive the newer token, but instead his wallet crea=
ted an address for the old token. It is the responsibility of the receiver =
to write a correct invoice. This is the case everywhere else in the world t=
oo, so this seems like a reasonable trade-off.<br>
<br>
I would even argue that this should hold in a legal case, where the receive=
r cannot claim that he was expecting a payment in another token (contrary t=
o how it is today, like when users send BTC to a BCH address, losing their =
funds with potentially no legal right for reimbursement). If I sent someone=
an invoice over 100=E2=82=AC, I cannot later proclaim that I actually expe=
cted $100.<br>
<br>
With this proposal, wallets are finally able to distinguish between differe=
nt tokens. With this ability, I expect to see different implementations, so=
me wallets which advertise staying conservative, following a strict ruleset=
, and other wallets being more experimental, following hashing rate or othe=
r metrics.<br>
<br>
</blockquote></div></div>
--94eb2c184b14652b42055d92e3e8--
|
