path: root/61/ef559aa010604e2dbc24d87e3f4959fdee02a6

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1V7qwd-0000dE-R1
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 17:57:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.44 as permitted sender)
	client-ip=209.85.128.44; envelope-from=etotheipi@gmail.com;
	helo=mail-qe0-f44.google.com; 
Received: from mail-qe0-f44.google.com ([209.85.128.44])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V7qwZ-00046G-Dp
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 17:57:47 +0000
Received: by mail-qe0-f44.google.com with SMTP id 6so2541367qeb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 09 Aug 2013 10:57:37 -0700 (PDT)
X-Received: by 10.224.156.69 with SMTP id v5mr12228964qaw.113.1376071057844;
	Fri, 09 Aug 2013 10:57:37 -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
	m10sm23761853qae.12.2013.08.09.10.57.36
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 09 Aug 2013 10:57:37 -0700 (PDT)
Message-ID: <52052D8F.90706@gmail.com>
Date: Fri, 09 Aug 2013 13:57:35 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
	<51C21035.9080407@gmail.com>
	<53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
	<51C234FA.5030909@gmail.com>
	<9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
	<CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com>
	<51CB08EE.1050403@gmail.com>
In-Reply-To: <51CB08EE.1050403@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative;
	boundary="------------050902000309000109060401"
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: 1V7qwZ-00046G-Dp
Subject: [Bitcoin-development] Optional "wallet-linkable" address format
	(Re-request)
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: Fri, 09 Aug 2013 17:57:48 -0000

This is a multi-part message in MIME format.
--------------050902000309000109060401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Guys,

I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol.  We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it and can be safely ignored by others.

Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
checksum)
Alternate format:         binary_to_base58( idbyte + parentpubkey +
multiplier + checksum)

The receiving party will multiply the pubkey by the multiplier, and then
hash it to get the 20-byte address to send to.  The idea is that you use
your BIP 32 parent public key, and then you generate whatever child you
want, and only send them the multiplier used (not the chaincode).  This
preserves privacy, but if the recipient has your parent public key
already, they can identify that address being linked to you, but cannot
determine any other addresses in your wallet.

This form has no drawbacks to the existing address format except for
being longer and requiring an extra EC multiplication by the person
sending to that address.  But the advantage is that it optionally allows
the sender to provide more information than currently contained in the
25-byte hash160 form.  The discussion about this got side-tracked with
the use case I presented, but I believe there are plenty of other uses
for this.

The particular use case I had in mind was that certain services could be
setup (pre-arranged), say between wallet software and a
business/exchange.  The exchange would like to be able to reliably send
addresses to the user for deposit, without risk of MITM, or even if
their own public server is compromised.  The author of wallet software
pre-verifies the public key portion of the service, and either hardcodes
it into the software, or hardcodes their own public key into the
software and makes the service's signed public key available through
query server (allowing the software author to offline-sign replacement
keys, or add keys for new service providers, as needed). 

When the user's software receives a payment address, the software can
verify it belongs to that service.  You can't use dedicated chain
technique, because it would either have to be exchanged with the user on
first transaction which half defeats the purpose, or they give them the
full public key and chaincode which allows the user to see /all
/addresses ever used by the service.  Neither one is a reasonable solution.

This use case doesn't necessarily scale, but it doesn't have to.  It
simply allows service providers to skip the SSL and go right to public
key exchange/verification for a few of the important services they
provide access to, and will provide better security than relying on
SSL/PKI.  This would simply be one, coexisting option for providing
payment details in the absence (or in addition to) SSL/PKI infrastructure.

I'm sure there's other use cases, but it seems simple enough and
non-disruptive enough that it could be supported easily for no other
reason than to support that use case (which I intend to implement in
Armory to help verify high-volume services).

-Alan





On 06/26/2013 11:29 AM, Alan Reiner wrote:
> Although I'd still prefer my original request, I get much of what I
> want from your guys' recommendation.  It complicates the wallet
> design, because it requires tracking and associating a matrix of
> addresses for each wallet, instead of a single linear list.  But if
> this is what it's going to take then I will go along. 
>
> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
> used for distributing addresses, and j=1 is the "internal" chain for
> sending change.  The CONOPs (concept of operations) for the extended
> wallet would be like Jeremy described:
>
> - Chains with j>=2 would be independent address chains carved out for
> individuals relationships
> - Add wallet code to individually associate each j-value with a
> particular identity
> - Update the wallet code to pool all the addresses in all j-chains
> when calculating the balance of the wallet and/or creating transactions
> - When choosing to generically "Receive Bitcoins", will pick the next
> address from the j=0 chain
> - Will have to add extra function to "Receive Bitcoins" button to
> allow creation of new contacts/identities.
> - Change will always go to the next address in j=1, no matter which
> chains are used to provide inputs.
> - Add code to figure out lookaheads for each alternate chain.  Not
> just each chain, but looking ahead a couple chains, too.  Luckily, the
> lookahead doesn't have to be very big for chains j>=1 
> - Add an interface to display and choose the different chains in your
> wallet, and export the pubkey&chaincode in some
> soon-to-be-standardized format. 
> - Add code and interface to receive and track alternate j-chains from
> other clients/users, and maintain those.  Should we try associating
> incoming and outgoing chains?  What happens if they do it wrong?  Meh...
>
> Just as one final swipe at this idea, you can see that I gotta do
> quite a bit of work to support the multi-chain idea, and adds a little
> extra burden on the user to maintain the organization of the wallet. 
> This would all be totally unnecessary with a simple alternate
> encoding.  Granted, I think the multi-chain idea is good, and one that
> I will probably implement anyway, but it seems like overkill in terms
> of developer complexity, and interface complexity to achieve something
> much simpler.  Developers of much simpler/lightweight clients would
> probably find this prohibitive.
>
> On another note:  I thought we weren't encouraging automatic payments
> without requesting from the other party...?  It makes me uneasy, but
> it sounds like group thought has converged on that being acceptable. 
> I bring it up, because there are situations where it makes sense, but
> it sounds unsafe for general users.   Alice will give Bob his own
> chain for sending Alice money, then a year later Bob will send money
> automatically to Alice not realizing that the wallet was lost, retired
> or compromised.  It's not that Bob can't ask for a new address, it's
> that if the interface says "Send Money to Alice", that looks legit
> enough that Bob may not feel it necessary to check with Alice first.  
> That's more of an interface issue though.  We can add a warning to
> "check with the recipient that they still have access to wallet
> 3cQ398x", etc.   But I just know someone is going to lose money anyway...
>
> -Alan
>
>
>
>
>
> On 06/20/2013 03:32 AM, Mike Hearn wrote:
>> Agree with Jeremy and once the payment protocol work is further along
>> I'd like to see us define an extension that lets you send payment
>> requests containing public keys+chain codes, so further payments can
>> be made push-style with no recipient interaction (e.g. for repeated
>> billing). How apps choose to arrange their chains internally seems
>> like an area for experimentation. I definitely want to implement HD
>> wallets in bitcoinj to allow this and if that means not using the
>> same tree structure as in the BIP then so be it.
>>
>>
>> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co
>> <mailto:jeremy@taplink.co>> wrote:
>>
>>     > 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.
>>
>>     Initially I was thinking that you would share the public key and
>>     chain code
>>     from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
>>     a unique
>>     value of 'i' for each receive chain.
>>
>>     For the case of generating new receive chains from a *watch-only*
>>     wallet, as
>>     you say, the options are to either keep a cache of
>>     PubKey/ChainCode for
>>     unused [m/i'] or simply increment 'j' past 1 for an existing
>>     [m/i'/j] -- the
>>     concept of 'internal/'external' and change addresses at Depth=2
>>     don't make
>>     sense for handing out receive chains to lots of people anyway,
>>     and certainly
>>     BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j'
>>     is the way
>>     to go here...
>>
>>     The "default" layout of BIP32 does NOT mean that implementations
>>     should not
>>     check for transactions with j > 1. That would be a useless
>>     constraint and
>>     obviously self-limiting. It might be helpful to add to the
>>     'Compatibility'
>>     section some minimum expectations about how a wallet should be
>>     'probed' when
>>     imported. If you don't feel completely free to monotonically
>>     increment 'j'
>>     to your hearts content to achieve major usability benefits, then
>>     I say BIP32
>>     could use some clarifying.
>>
>>     BTW - the spec calls for addition not multiplication now, so we
>>     should call
>>     it the 'Addend' not the 'Multiplier' :-)
>>
>>     > Do these extra wallet chains behave as different wallets, or
>>     sub-wallets?
>>
>>     They could, but they certainly don't need to!  A single-wallet
>>     implementation treats this merely as an address-generation
>>     algorithm, and
>>     does not expose any hierarchy to the user interface.  The user just
>>     "magically" gets the ability to send multiple payments to their
>>     contacts
>>     without immediately sacrificing their privacy
>>     (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
>>     Everything
>>     goes into the same ledger, balance, coin pool, etc. Most of the
>>     code base is
>>     unaware BIP32 is even in use.
>>
>>     While it is *possible* to support separate ledgers, balances,
>>     etc. it is
>>     certainly not required, and you get all the benefits either way.
>>
>>     I think, since your proposal generates and receives payments into
>>     BIP32-style addresses, we both need similar underlying wallet
>>     code. The only
>>     difference is that you are passing the Kpar for [m/i'/0/k] and
>>     the *result*
>>     of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and
>>     cpar, and
>>     leaving 'k' out of it, letting the receive choose 'k'.
>>
>>     > 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.
>>
>>     I think it's a interesting idea using static public keys as a
>>     means for
>>     persistent identity and hence security from MitM. If you want a
>>     shared
>>     public key across multiple services we could just combine both
>>     ideas and get
>>     all the benefits, by making the data structure { ParentPubKey,
>>     Addend,
>>     ChainCode }:
>>
>>        ParentPubKey: Public key of m/i' -- 33 bytes
>>        Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>>        ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>>
>>     All that remains secret is the ChainCode from [m/i'] -- and of
>>     course the
>>     private keys.  The ParentPubKey is a common value across multiple
>>     services,
>>     corresponding to user's identity rooted in [m/i'].  Each service
>>     gets their
>>     own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].
>>      With the
>>     ChainCode, the receiver then can generate [m/i'/j/k] for
>>     monotonically
>>     increasing 'k'. Again, from the user perspective all transactions
>>     under
>>     [m/i'] can be presented in a single ledger, or not.
>>
>>     Anyway, fundamentally my feedback is if you are designing for
>>     persistent
>>     long-term relationships, you could build in a mechanism for
>>     generating
>>     address chains so you don't need any further communication after
>>     the initial
>>     exchange, and it need not complicate the wallet.
>>
>>     Thanks,
>>     --Jeremy
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     This SF.net email is sponsored by Windows:
>>
>>     Build for Windows Store.
>>
>>     http://p.sf.net/sfu/windows-dev2dev
>>     _______________________________________________
>>     Bitcoin-development mailing list
>>     Bitcoin-development@lists.sourceforge.net
>>     <mailto:Bitcoin-development@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


--------------050902000309000109060401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Guys, <br>
    <br>
    I'd like to reiterate my previous request to support this alternate
    address serialization in the payment protocol.&nbsp; We got caught up in
    the specifics of one use case, but didn't acknowledge that it's
    still a valid address representation that will provide value to
    those who wish to use it and can be safely ignored by others.<br>
    <br>
    <tt>Current address format:&nbsp;&nbsp; binary_to_base58( idbyte +
      hash160(pubkey) + checksum)</tt><tt><br>
    </tt><tt>Alternate format:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; binary_to_base58( idbyte +
      parentpubkey + multiplier + checksum)</tt><br>
    <br>
    The receiving party will multiply the pubkey by the multiplier, and
    then hash it to get the 20-byte address to send to.&nbsp; The idea is
    that you use your BIP 32 parent public key, and then you generate
    whatever child you want, and only send them the multiplier used (not
    the chaincode).&nbsp; This preserves privacy, but if the recipient has
    your parent public key already, they can identify that address being
    linked to you, but cannot determine any other addresses in your
    wallet.<br>
    <br>
    This form has no drawbacks to the existing address format except for
    being longer and requiring an extra EC multiplication by the person
    sending to that address.&nbsp; But the advantage is that it optionally
    allows the sender to provide more information than currently
    contained in the 25-byte hash160 form.&nbsp; The discussion about this
    got side-tracked with the use case I presented, but I believe there
    are plenty of other uses for this.<br>
    <br>
    The particular use case I had in mind was that certain services
    could be setup (pre-arranged), say between wallet software and a
    business/exchange.&nbsp; The exchange would like to be able to reliably
    send addresses to the user for deposit, without risk of MITM, or
    even if their own public server is compromised.&nbsp; The author of
    wallet software pre-verifies the public key portion of the service,
    and either hardcodes it into the software, or hardcodes their own
    public key into the software and makes the service's signed public
    key available through query server (allowing the software author to
    offline-sign replacement keys, or add keys for new service
    providers, as needed).&nbsp; <br>
    <br>
    When the user's software receives a payment address, the software
    can verify it belongs to that service.&nbsp; You can't use dedicated
    chain technique, because it would either have to be exchanged with
    the user on first transaction which half defeats the purpose, or
    they give them the full public key and chaincode which allows the
    user to see <i>all </i>addresses ever used by the service.&nbsp;
    Neither one is a reasonable solution.<br>
    <br>
    This use case doesn't necessarily scale, but it doesn't have to.&nbsp; It
    simply allows service providers to skip the SSL and go right to
    public key exchange/verification for a few of the important services
    they provide access to, and will provide better security than
    relying on SSL/PKI.&nbsp; This would simply be one, coexisting option for
    providing payment details in the absence (or in addition to) SSL/PKI
    infrastructure.<br>
    <br>
    I'm sure there's other use cases, but it seems simple enough and
    non-disruptive enough that it could be supported easily for no other
    reason than to support that use case (which I intend to implement in
    Armory to help verify high-volume services).<br>
    <br>
    -Alan<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 06/26/2013 11:29 AM, Alan Reiner
      wrote:<br>
    </div>
    <blockquote cite="mid:51CB08EE.1050403@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Although I'd still prefer my original request, I get much of what
      I want from your guys' recommendation.&nbsp; It complicates the wallet
      design, because it requires tracking and associating a matrix of
      addresses for each wallet, instead of a single linear list.&nbsp; But
      if this is what it's going to take then I will go along.&nbsp; <br>
      <br>
      Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external"
      chain used for distributing addresses, and j=1 is the "internal"
      chain for sending change.&nbsp; The CONOPs (concept of operations) for
      the extended wallet would be like Jeremy described:<br>
      <br>
      - Chains with j&gt;=2 would be independent address chains carved
      out for individuals relationships<br>
      - Add wallet code to individually associate each j-value with a
      particular identity<br>
      - Update the wallet code to pool all the addresses in all j-chains
      when calculating the balance of the wallet and/or creating
      transactions<br>
      - When choosing to generically "Receive Bitcoins", will pick the
      next address from the j=0 chain<br>
      - Will have to add extra function to "Receive Bitcoins" button to
      allow creation of new contacts/identities.<br>
      - Change will always go to the next address in j=1, no matter
      which chains are used to provide inputs.<br>
      - Add code to figure out lookaheads for each alternate chain.&nbsp; Not
      just each chain, but looking ahead a couple chains, too.&nbsp; Luckily,
      the lookahead doesn't have to be very big for chains j&gt;=1&nbsp; <br>
      - Add an interface to display and choose the different chains in
      your wallet, and export the pubkey&amp;chaincode in some
      soon-to-be-standardized format.&nbsp; <br>
      - Add code and interface to receive and track alternate j-chains
      from other clients/users, and maintain those.&nbsp; Should we try
      associating incoming and outgoing chains?&nbsp; What happens if they do
      it wrong?&nbsp; Meh...<br>
      <br>
      Just as one final swipe at this idea, you can see that I gotta do
      quite a bit of work to support the multi-chain idea, and adds a
      little extra burden on the user to maintain the organization of
      the wallet.&nbsp; This would all be totally unnecessary with a simple
      alternate encoding.&nbsp; Granted, I think the multi-chain idea is
      good, and one that I will probably implement anyway, but it seems
      like overkill in terms of developer complexity, and interface
      complexity to achieve something much simpler.&nbsp; Developers of much
      simpler/lightweight clients would probably find this prohibitive.<br>
      <br>
      On another note:&nbsp; I thought we weren't encouraging automatic
      payments without requesting from the other party...?&nbsp; It makes me
      uneasy, but it sounds like group thought has converged on that
      being acceptable.&nbsp; I bring it up, because there are situations
      where it makes sense, but it sounds unsafe for general users. &nbsp;
      Alice will give Bob his own chain for sending Alice money, then a
      year later Bob will send money automatically to Alice not
      realizing that the wallet was lost, retired or compromised.&nbsp; It's
      not that Bob can't ask for a new address, it's that if the
      interface says "Send Money to Alice", that looks legit enough that
      Bob may not feel it necessary to check with Alice first.&nbsp;&nbsp; That's
      more of an interface issue though.&nbsp; We can add a warning to "check
      with the recipient that they still have access to wallet 3cQ398x",
      etc.&nbsp;&nbsp; But I just know someone is going to lose money anyway...<br>
      <br>
      -Alan<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 06/20/2013 03:32 AM, Mike Hearn
        wrote:<br>
      </div>
      <blockquote
cite="mid:CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com"
        type="cite">
        <div dir="ltr">Agree with Jeremy and once the payment protocol
          work is further along I'd like to see us define an extension
          that lets you send payment requests containing public
          keys+chain codes, so further payments can be made push-style
          with no recipient interaction (e.g. for repeated billing). How
          apps choose to arrange their chains internally seems like an
          area for experimentation. I definitely want to implement HD
          wallets in bitcoinj to allow this and if that means not using
          the same tree structure as in the BIP then so be it.</div>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Thu, Jun 20, 2013 at 5:54 AM,
            Jeremy Spilman <span dir="ltr">&lt;<a
                moz-do-not-send="true" href="mailto:jeremy@taplink.co"
                target="_blank">jeremy@taplink.co</a>&gt;</span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="im">&gt; BIP 32 already specifies how to use
                the first three tree levels: &nbsp;M/i/j/k,<br>
                &gt; i~wallet, j~Internal/External, k~address. &nbsp;The
                first level is actually<br>
                &gt; type-1 derived, and thus we cannot create an
                arbitrary number of them<br>
                &gt; without pre-computing them from the offline wallet.
                &nbsp;So it's not "free" to<br>
                &gt; create new wallets unless we redefine how the
                levels work.<br>
                <br>
              </div>
              Initially I was thinking that you would share the public
              key and chain code<br>
              from [m/i'/0] so that you can receive payments at
              [m/i'/0/k], for a unique<br>
              value of 'i' for each receive chain.<br>
              <br>
              For the case of generating new receive chains from a
              *watch-only* wallet, as<br>
              you say, the options are to either keep a cache of
              PubKey/ChainCode for<br>
              unused [m/i'] or simply increment 'j' past 1 for an
              existing [m/i'/j] -- the<br>
              concept of 'internal/'external' and change addresses at
              Depth=2 don't make<br>
              sense for handing out receive chains to lots of people
              anyway, and certainly<br>
              BIP32 doesn't *require* 0 &lt;= j &lt;= 1. &nbsp;So I think
              incrementing 'j' is the way<br>
              to go here...<br>
              <br>
              The "default" layout of BIP32 does NOT mean that
              implementations should not<br>
              check for transactions with j &gt; 1. That would be a
              useless constraint and<br>
              obviously self-limiting. It might be helpful to add to the
              'Compatibility'<br>
              section some minimum expectations about how a wallet
              should be 'probed' when<br>
              imported. If you don't feel completely free to
              monotonically increment 'j'<br>
              to your hearts content to achieve major usability
              benefits, then I say BIP32<br>
              could use some clarifying.<br>
              <br>
              BTW - the spec calls for addition not multiplication now,
              so we should call<br>
              it the 'Addend' not the 'Multiplier' :-)<br>
              <div class="im"><br>
                &gt; Do these extra wallet chains behave as different
                wallets, or sub-wallets?<br>
                <br>
              </div>
              They could, but they certainly don't need to! &nbsp;A
              single-wallet<br>
              implementation treats this merely as an address-generation
              algorithm, and<br>
              does not expose any hierarchy to the user interface. &nbsp;The
              user just<br>
              &#8220;magically&#8221; gets the ability to send multiple payments to
              their contacts<br>
              without immediately sacrificing their privacy<br>
              (<a moz-do-not-send="true"
                href="http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/"
                target="_blank">http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/</a>).

              Everything<br>
              goes into the same ledger, balance, coin pool, etc. Most
              of the code base is<br>
              unaware BIP32 is even in use.<br>
              <br>
              While it is *possible* to support separate ledgers,
              balances, etc. it is<br>
              certainly not required, and you get all the benefits
              either way.<br>
              <br>
              I think, since your proposal generates and receives
              payments into<br>
              BIP32-style addresses, we both need similar underlying
              wallet code. The only<br>
              difference is that you are passing the Kpar for [m/i'/0/k]
              and the *result*<br>
              of CKD'((Kpar, cpar), k), and instead I proposed passing
              Kpar and cpar, and<br>
              leaving 'k' out of it, letting the receive choose 'k'.<br>
              <div class="im"><br>
                &gt; For instance, maybe there's a benefit to using the
                same parent pubkey<br>
              </div>
              &gt; across multiple services, as a form of identity. &nbsp; If
              I don't want that, I<br>
              <div class="im">&gt; use your method. &nbsp;If I do want that,
                I use my method.<br>
                <br>
              </div>
              I think it's a interesting idea using static public keys
              as a means for<br>
              persistent identity and hence security from MitM. If you
              want a shared<br>
              public key across multiple services we could just combine
              both ideas and get<br>
              all the benefits, by making the data structure {
              ParentPubKey, Addend,<br>
              ChainCode }:<br>
              <br>
              &nbsp; &nbsp;ParentPubKey: Public key of m/i' -- 33 bytes<br>
              &nbsp; &nbsp;Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes<br>
              &nbsp; &nbsp;ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes<br>
              <br>
              All that remains secret is the ChainCode from [m/i'] --
              and of course the<br>
              private keys. &nbsp;The ParentPubKey is a common value across
              multiple services,<br>
              corresponding to user's identity rooted in [m/i']. &nbsp;Each
              service gets their<br>
              own 'j'. &nbsp;ParentPubKey + Addend gives you the PubKey of
              [m/i'/j]. &nbsp;With the<br>
              ChainCode, the receiver then can generate [m/i'/j/k] for
              monotonically<br>
              increasing 'k'. Again, from the user perspective all
              transactions under<br>
              [m/i'] can be presented in a single ledger, or not.<br>
              <br>
              Anyway, fundamentally my feedback is if you are designing
              for persistent<br>
              long-term relationships, you could build in a mechanism
              for generating<br>
              address chains so you don't need any further communication
              after the initial<br>
              exchange, and it need not complicate the wallet.<br>
              <div class="HOEnZb">
                <div class="h5"><br>
                  Thanks,<br>
                  --Jeremy<br>
                  <br>
                  <br>
                  <br>
------------------------------------------------------------------------------<br>
                  This SF.net email is sponsored by Windows:<br>
                  <br>
                  Build for Windows Store.<br>
                  <br>
                  <a moz-do-not-send="true"
                    href="http://p.sf.net/sfu/windows-dev2dev"
                    target="_blank">http://p.sf.net/sfu/windows-dev2dev</a><br>
                  _______________________________________________<br>
                  Bitcoin-development mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
                  <a moz-do-not-send="true"
                    href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
                    target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sfu/windows-dev2dev</a></pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------050902000309000109060401--