summaryrefslogtreecommitdiff
path: root/c2/e4fb078bf5a067dafea317b058b68ec7fe7f09
blob: b50f43b4102db0b38b15db3546325acd7d0e7ce5 (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
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 62A8EC09
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Apr 2017 19:26:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7AAC9108
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Apr 2017 19:26:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101])
	by mx-out02.mykolab.com (Postfix) with ESMTPS id C135B607C6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Apr 2017 21:26:13 +0200 (CEST)
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Fri, 14 Apr 2017 21:26:14 +0200
Message-ID: <2112201.An0daUyfG4@cherry>
In-Reply-To: <CAFz7pMuMMmR=nrk9ho+0Gir-C7JVVn1GzA=6JsQV9NYF2WfP5w@mail.gmail.com>
References: <CAFz7pMuMMmR=nrk9ho+0Gir-C7JVVn1GzA=6JsQV9NYF2WfP5w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 14 Apr 2017 19:41:29 +0000
Subject: Re: [bitcoin-dev] BIP proposal draft: BIP43 "purpose" allocation
	for Ethereum
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, 14 Apr 2017 19:26:17 -0000

Thinking about this a bit, I support this proposal for a BIP.
This is not Bitcoin, but address types are bound to meet in meat-space and 
it would be good to have a central place where this is defined.

I would very much appreciate someone that worked on BIP32/BIP43 itself to 
comment on the details.

Quoting bip 43;


"We encourage different schemes to apply for assigning a separate BIP
number and use the same number for purpose field, so addresses won't be
generated from overlapping BIP32 spaces."



On Wednesday, 12 April 2017 12:02:37 CEST Nick Johnson via bitcoin-dev 
wrote:
> <pre>
>   BIP: bip-nickjohnson-ethereum-purpose
>   Layer: Applications
>   Title: Ethereum purpose allocation for Deterministic Wallets
>   Author: Nick Johnson <nick@ethereum.org>
>   Status: Proposed
>   Type: Standards Track
>   Created: 2017-04-12
> </pre>
> 
> ==Abstract==
> 
> This BIP defines a logical hierarchy for deterministic wallets on the
> Ethereum blockchain based on an algorithm described in BIP-0032 (BIP32
> from now on) and purpose scheme described in BIP-0043 (BIP43 from now
> on).
> 
> This BIP is a particular application of BIP43.
> 
> ==Motivation==
> 
> Because Ethereum is based on account balances rather than UTXO, the
> hierarchy defined by BIP44 is poorly suited. As a result, several
> competing derivation path strategies have sprung up for deterministic
> wallets, resulting in inter-client incompatibility. This BIP seeks to
> provide a path to standardise this in a fashion better suited to
> Ethereum's unique requirements.
> 
> ==Path levels==
> 
> We define the following 2 levels in BIP32 path:
> 
> <pre>
> m / purpose' / subpurpose' / *
> </pre>
> 
> Apostrophe in the path indicates that BIP32 hardened derivation is used.
> 
> Each level has a special meaning, described in the chapters below.
> 
> ===Purpose===
> 
> Purpose is a constant set to the hardened value of the BIP number assigned
> to this BIP (equivalently, the BIP number, bitwise ORed with 0x80000000)
> following the BIP43 recommendation.
> It indicates that the subtree of this node is used according to this
> specification.
> 
> Hardened derivation is used at this level.
> 
> ===Subpurpose===
> Subpurpose is set to the EIP number specifying the remainder of the BIP32
> derivation path. This permits new Ethereum-focused applications of
> deterministic wallets without needing to interface with the BIP process.
> 
> Hardened derivation is used at this level.
> 
> ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic
> Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic
> Wallets]]


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel