<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:<br>
<blockquote cite="mid:5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<div dir="ltr">
<div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR:
#000000">
<div>
<div style="FONT-SIZE: small; FONT-FAMILY: 'Calibri';
FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal;
TEXT-DECORATION: none; DISPLAY: inline">If you have two
parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I
think the canonical way to do this with BIP32 is for the
parties to exchange PubKey and *ChainCode*.</div>
<div dir="ltr">
<div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri';
COLOR: #000000">
<div> </div>
<div>I don’t understand the use case for handing out
individual multipliers, if what you desire is a
persistent relationship. If each party dedicates a
child-wallet for receiving coins, and saves a
PubKey/ChainCode for sending coins, the two parties
can transaction securely forever without ever
exchanging any more information, and without any
address reuse.</div>
<div> </div>
<div>I think ideally, the default behavior is that
wallets always dedicate a new child node {PubKey,
ChainCode} to each party they transact with. At the
presentation layer, you have a “contact” and each
contact has a transaction history. You can send coins
to a contact at any time, and internally the wallet
picks the next address in their sequence. Any funds
received on pubkeys from contact’s sequence are
attributed to that contact. The wallet can organize
the contacts, and roll-up the transaction history into
‘ledgers’ and ‘balances’ however they want – it could
be based on the underlying BIP32 hierarchy or perhaps
not. The cost of watching large a number of pubkeys,
even if you ‘look ahead’ 100 pubkeys for each contact,
is relatively small versus the benefits.</div>
<div> </div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
What you just described is complimentary to what I am proposing.
There is nothing stopping you from doing it that way, except that it
may be inconvenient in some circumstances. 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). And all separate chains with their 100-address look-aheads
may be fine for your desktop or mobile device, but maybe not a HW
signing device with 128 kB of memory. <br>
<br>
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across
many contacts. For instance, maybe there's a benefit to using the
same parent pubkey across multiple services, as a form of
identity. If I don't want that, I use your method. If I do want
that, I use my method. Given its simplicity, I don't know why both
can't be options.<br>
<br>
Actually, it doesn't have to be specific to the payment protocol, it
can just be alternative address encoding that some apps would use if
they have a need for it. <br>
<br>
-Alan<br>
</body>
</html>