<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=content-type></HEAD>
<BODY dir=ltr bgColor=#ffffff text=#000000>
<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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV>What might be nice is a ‘Contact Request’ protocol, basically the same as a 
PaymentRequest but no actual payments are sent, just child wallets 
created:</DIV>
<DIV>&nbsp;</DIV>
<DIV>message Contact {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional uint32 contact_version = 1 [default = 1];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string pki_type = 2 [default = "none"];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional bytes pki_data = 3;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes serialized_contact_details = 4;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional bytes signature = 5;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>message ContactDetails {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string network = 1 [default = "main"];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes pubkey = 2;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes chaincode = 3;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string memo = 4;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string response_url = 5;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Alice sends a Contact+ContactDetails to Bob.&nbsp; If Bob accepts, he sends 
his own Contact+ContactDetails (without a response_url) back to Alice. Basically 
just like adding a contact to your IM contacts.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Alice could send a Contact+ContactDetails to Bob without a response_url, in 
which case after accepting the contact, Bob could send funds to Alice, but not 
receive funds.</DIV>
<DIV>&nbsp;</DIV>
<DIV>You could probably pack the whole message inside a bitcoin:// URI if you 
wanted to.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>--Jeremy</DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML>