<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>