summaryrefslogtreecommitdiff
path: root/f8/d7277af578e45842c286917d76bc8bee699cdf
blob: 5187a33a8196b3b8827dd86cc0254d0c9c3e01b7 (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
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 2592587A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  8 Nov 2017 16:45:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E2BC4561
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  8 Nov 2017 16:45:06 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id z3so12137301wme.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 08 Nov 2017 08:45:06 -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=Azkg28QTSwX+u3UMxeVaOLaQBPtFnq/46UnMSS80txQ=;
	b=NTfSP0goNZQYjX0OZAzvwgYq2nhmNmtlIK5x4K/Ix+QypUE+m9JjVEhM921XOnBJMZ
	frdicGe8iBeysyz2jbeHZj96JwcbAI+001IvZgaaC+fW6dbcTwLLVD0HdYd4/VkM6PBB
	wjA1YEIwW51hLfiPpHNZHAMitwLK9343pR/fY=
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=Azkg28QTSwX+u3UMxeVaOLaQBPtFnq/46UnMSS80txQ=;
	b=G8VTKR58E53Q20P1DG8r7QV8NobiwPbTc8Cf1N23FOwH/zGgGLXEk5sa5ceZG6qZh6
	x+ZqHBTIRm3oggRKi+rWRZ94KsXGt529Q/zIbs0a0uyZIIyraqA9L4f7DusYkg1aP+KB
	o8YrUmwLm5RnJXqeb1VLw3akd8VaEFHmfNEWM08Z6N+n1HZhKxqpzam1nrEscx12NVzU
	5VbGil9YXpb4+QkiiDbJPo5Q6ZuWdVJBoa3iYbHODRA3esYIvWxs1BCzh3+AarcFOZtD
	aeYP9dcfMs7ImWIcwQbQn3MsvfRRuOzWqqkAiYrvBlgRxeing2YQxyhMCrfCPEbXl4WI
	wRsg==
X-Gm-Message-State: AJaThX5fLc0CfDldAdfG4S5NEB+uOpOCboiEwbTlmTRQqOeVNiVUiFC1
	NbMOAQURD112ViBRr+AeN8omBA==
X-Google-Smtp-Source: ABhQp+Tmm/dByctQkmkztE4kkosey6vAd0OF7WBFKWpBT6IdX9fBF4gnQjLAoCU+Qt68PwDpCtNIgA==
X-Received: by 10.28.224.87 with SMTP id x84mr864165wmg.118.1510159505264;
	Wed, 08 Nov 2017 08:45:05 -0800 (PST)
Received: from [10.2.1.168] ([212.161.45.230])
	by smtp.gmail.com with ESMTPSA id
	d195sm2395028wmd.30.2017.11.08.08.45.03
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 08 Nov 2017 08:45:04 -0800 (PST)
From: Mats Jerratsch <mats@blockchain.com>
Message-Id: <C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_44BDD102-B4A4-411E-83C2-315051FE0679";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 8 Nov 2017 16:45:01 +0000
In-Reply-To: <CAAUaCyiZ0bmWZLZc-yDvVHupzbdRR=Kdq4P8VkWqpU1L3G-u3A@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>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,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: Wed, 08 Nov 2017 16:45:35 +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: Wed, 08 Nov 2017 16:45:08 -0000


--Apple-Mail=_44BDD102-B4A4-411E-83C2-315051FE0679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 =
wallet 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.


--Apple-Mail=_44BDD102-B4A4-411E-83C2-315051FE0679
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

iQIcBAEBCgAGBQJaAzSOAAoJEAYZmwZ/PsbKTU0QAIixf5AaL14W62IeWwcG7GyE
1/ECncf1DAHNURWRocU6UU1mxVxFwgJDMpTm4oPLrtS7UIrsChf5E3Zmy0+OFly7
UN/Fj23XB3kBE4abPkfGUumklXOvWYDmK4sD5x2H0i4JOHYUuD4dg2J3tL044XZX
daK656sA+Q+nQru5waaP3kKr/3J5hT0QzihedIFS7WPN1GZfqUWQU+HDY8UOqCH+
K33NYZNAAO3q5Turt9WWkODwyiQahLmZBcQqmuncJsG1wOL4+lsiFrBXL6MCOoq4
+0wk04qXhZLa9MFv87sNZ4wILKic+pR/5J2rxc9Y3THfyly+Oa3mNS5+vM/+yx7o
Qdm8mKBvND/HOaSSx4iC+y9Ldckn5tnv9GJDzeTAqCLCYBusX/I4nV+GEU3sgqxi
0o/zmjxiSQZv3TxHrmkmweuZA+426Nwxch87T7H8UrWNKU+qgHJivMfNp7658iwu
qo0zuega9UXvNuM1+E9Jsgf4t4v4epDbLCRNWa3AU86EFXyk5ZYqQQjC+DZqyEDI
DKuRvOlCWjV1tmFl442pFrENHjMnd0hIu4IMs8TcUUbKovYLePW8WyW2lQ06Zh1o
Eu3xyGgfwQbiTIEgRXK2lNm7MrSzr3MjJsCalySDJ4o8d4H8U5Gj/t2WYFz2oyJ0
I1P4BxspOUbHWuXohOgD
=jfwy
-----END PGP SIGNATURE-----

--Apple-Mail=_44BDD102-B4A4-411E-83C2-315051FE0679--