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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UpRAA-00047J-Nb
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 22:47:38 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.174 as permitted sender)
client-ip=209.85.223.174; envelope-from=etotheipi@gmail.com;
helo=mail-ie0-f174.google.com;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UpRA9-0004Oz-R5
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 22:47:38 +0000
Received: by mail-ie0-f174.google.com with SMTP id 9so14614837iec.19
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Jun 2013 15:47:32 -0700 (PDT)
X-Received: by 10.50.141.234 with SMTP id rr10mr2544295igb.34.1371682052547;
Wed, 19 Jun 2013 15:47:32 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id nm17sm8258248igb.5.2013.06.19.15.47.31
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 19 Jun 2013 15:47:31 -0700 (PDT)
Message-ID: <51C234FA.5030909@gmail.com>
Date: Wed, 19 Jun 2013 18:47:22 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
<51C21035.9080407@gmail.com>
<53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
In-Reply-To: <53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------060407020704010004030501"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UpRA9-0004Oz-R5
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
- Payment Protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 22:47:38 -0000
This is a multi-part message in MIME format.
--------------060407020704010004030501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
> Hi Alan,
>
>> “BIP 32 does not prescribe a way to use multiple chains like you described
>> with the convenient type-2 derivation (though we could create a variant
>> that does)”
> What do you think is missing from BIP32 for this? A wallet creates a
> child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
> and then generally expects transactions to come in starting at /0 and
> incrementing monotonically.
>
You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting. I
disagree. I am okay with using different wallets for different parties
*/if the user wants to/*. But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services. And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.
BIP 32 already specifies how to use the first three tree levels:
M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet. So it's not
"free" to create new wallets unless we redefine how the levels work.
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
-- Do these extra wallet chains behave as different wallets, or
sub-wallets?
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism? Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.
All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet. With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity. If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets. But it's not the only way.
To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications.
-Alan
--------------060407020704010004030501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/19/2013 05:58 PM, Jeremy Spilman wrote:<br>
<blockquote cite="mid:53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR"
type="cite">
<pre wrap="">Hi Alan,
</pre>
<blockquote type="cite">
<pre wrap="">“BIP 32 does not prescribe a way to use multiple chains like you described
with the convenient type-2 derivation (though we could create a variant
that does)”
</pre>
</blockquote>
<pre wrap="">
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
and then generally expects transactions to come in starting at /0 and
incrementing monotonically.
</pre>
</blockquote>
<br>
<br>
You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting. I
disagree. I am okay with using different wallets for different
parties <b><i>if the user wants to</i></b>. But there are
orthogonal use-cases to having a single wallet serve as a single
identity that can be used across multiple transactions or services.
And doing so is much simpler conceptually for the user, and simpler
in implementation for the app developer. <br>
<br>
BIP 32 already specifies how to use the first three tree levels:
M/i/j/k, i~wallet, j~Internal/External, k~address. The first level
is actually type-1 derived, and thus we cannot create an arbitrary
number of them without pre-computing them from the offline wallet.
So it's not "free" to create new wallets unless we redefine how the
levels work. Even if we assume the simplest case where the first
level is actually type-2 derived and it costs nothing to create
separate wallets for each contact/party:<br>
<br>
-- Do these extra wallet chains behave as different wallets, or
sub-wallets? <br>
-- Should their balances be bundled into a single wallet or
displayed separately?<br>
-- When a user tries to spend, does he have to specify which
wallet(s) he's spending from?<br>
-- Should the app developer be required to implement a
multiple-wallet interface, and handle cross-wallet spending just to
achieve this simple mechanism? Sure, they could instead implement a
tiered wallet hierarchy with primary wallets and sub-wallets... wait
this just got complicated.<br>
<br>
All that complexity just to support this identity mechanism that can
be included purely as an alternative address encoding with a single
wallet. With my request, the user can't have one wallet and
distribute most of his addresses the normal/anonymous way, but
certain apps would choose to use the alternate encoding as a form of
identity. If the user feels the need to create a separate wallet
for certain operations to separate his identities, that is his
option if the software supports multiple wallets. But it's not the
only way.<br>
<br>
To achieve what I'm suggesting is useful and trivial to implement
even in the simplest wallet applications. <br>
<br>
-Alan<br>
</body>
</html>
--------------060407020704010004030501--
|
