<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>&nbsp;</div>
                <div>I don&#8217;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 &#8220;contact&#8221; 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&#8217;s sequence are
                  attributed to that contact. The wallet can organize
                  the contacts, and roll-up the transaction history into
                  &#8216;ledgers&#8217; and &#8216;balances&#8217; however they want &#8211; it could
                  be based on the underlying BIP32 hierarchy or perhaps
                  not. The cost of watching large a number of pubkeys,
                  even if you &#8216;look ahead&#8217; 100 pubkeys for each contact,
                  is relatively small versus the benefits.</div>
                <div>&nbsp;</div>
                <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What you just described is complimentary to what I am proposing.&nbsp;
    There is nothing stopping you from doing it that way, except that it
    may be inconvenient in some circumstances.&nbsp; 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).&nbsp; 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.&nbsp; <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.&nbsp; For instance, maybe there's a benefit to using the
    same parent pubkey across multiple services, as a form of
    identity.&nbsp;&nbsp; If I don't want that, I use your method.&nbsp; If I do want
    that, I use my method.&nbsp; 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>