path: root/92/76dd44771ee9b8fe05556ba0278c716169ac37

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1V7t3W-0001ls-5r
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 20:13:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.172 as permitted sender)
	client-ip=209.85.216.172; envelope-from=etotheipi@gmail.com;
	helo=mail-qc0-f172.google.com; 
Received: from mail-qc0-f172.google.com ([209.85.216.172])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V7t3T-0002XQ-Tt
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 20:13:02 +0000
Received: by mail-qc0-f172.google.com with SMTP id a1so1953733qcx.17
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 09 Aug 2013 13:12:54 -0700 (PDT)
X-Received: by 10.224.127.196 with SMTP id h4mr12268129qas.59.1376079174328;
	Fri, 09 Aug 2013 13:12:54 -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 lk8sm21837297qeb.3.2013.08.09.13.12.53
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 09 Aug 2013 13:12:53 -0700 (PDT)
Message-ID: <52054D44.5050006@gmail.com>
Date: Fri, 09 Aug 2013 16:12:52 -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: Mike Hearn <mike@plan99.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> <52052D8F.90706@gmail.com>
	<CANEZrP1r3XCLpfjZdO5AymdrYi2CndxHH9HcB+NDas1TpOfUhQ@mail.gmail.com>
In-Reply-To: <CANEZrP1r3XCLpfjZdO5AymdrYi2CndxHH9HcB+NDas1TpOfUhQ@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative;
	boundary="------------050803000509070405080005"
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: 1V7t3T-0002XQ-Tt
X-Mailman-Approved-At: Fri, 09 Aug 2013 21:51:21 +0000
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 20:13:02 -0000

This is a multi-part message in MIME format.
--------------050803000509070405080005
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

That's fine.  I just want to make sure it's considered for inclusion at
some point, because I really hope to leverage the "identity" mechanism I
just described, and it's much easier if it's part of a standard instead
of convincing others to go around the standard with us.

I have not spent much time looking at the payment protocol itself.  I
didn't feel like I'd have much to contribute (besides requesting a
feature I know isn't there).  I was planning to wait until it was
complete before fully grokking and implementing it in Armory.


On 08/09/2013 03:58 PM, Mike Hearn wrote:
> Payment protocol is locked down for v1 already. But did you read it?
> It doesn't use addresses anywhere. Payments are specified in terms of
> a list of outputs which can contain any script. Of course it could be
> a pay-to-address script, but pay-to-address uses more bytes in the
> chain and there isn't any typeability benefit.
>
> The multiplication trick for deterministic keys is a nice one and
> worth doing, but it has to be a v2 feature by this point. It's more
> important to get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner <etotheipi@gmail.com
> <mailto:etotheipi@gmail.com>> wrote:
>
>     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 <mailto:Bitcoin-development@lists.sourceforge.net>
>>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>     ------------------------------------------------------------------------------
>     Get 100% visibility into Java/.NET code with AppDynamics Lite!
>     It's a free troubleshooting tool designed for production.
>     Get down to code-level detail for bottlenecks, with <2% overhead.
>     Download for free and get started troubleshooting in minutes.
>     http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


--------------050803000509070405080005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    That's fine.  I just want to make sure it's considered for inclusion
    at some point, because I really hope to leverage the "identity"
    mechanism I just described, and it's much easier if it's part of a
    standard instead of convincing others to go around the standard with
    us.<br>
    <br>
    I have not spent much time looking at the payment protocol itself. 
    I didn't feel like I'd have much to contribute (besides requesting a
    feature I know isn't there).  I was planning to wait until it was
    complete before fully grokking and implementing it in Armory.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 08/09/2013 03:58 PM, Mike Hearn
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP1r3XCLpfjZdO5AymdrYi2CndxHH9HcB+NDas1TpOfUhQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Payment protocol is locked down for v1 already. But
        did you read it? It doesn't use addresses anywhere. Payments are
        specified in terms of a list of outputs which can contain any
        script. Of course it could be a pay-to-address script, but
        pay-to-address uses more bytes in the chain and there isn't any
        typeability benefit.
        <div>
          <br>
        </div>
        <div>The multiplication trick for deterministic keys is a nice
          one and worth doing, but it has to be a v2 feature by this
          point. It's more important to get v1 widely implemented and
          deployed first.</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Fri, Aug 9, 2013 at 7:57 PM, Alan
          Reiner <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:etotheipi@gmail.com" target="_blank">etotheipi@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div 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. 
              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:   binary_to_base58( idbyte +
                hash160(pubkey) + checksum)</tt><tt><br>
              </tt><tt>Alternate format:         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.  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.<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.  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.<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.  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).  <br>
              <br>
              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 <i>all
              </i>addresses ever used by the service.  Neither one is a
              reasonable solution.<br>
              <br>
              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.<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>On 06/26/2013 11:29 AM, Alan Reiner wrote:<br>
              </div>
              <blockquote type="cite"> 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.  <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.  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.  Not just each chain, but looking ahead a couple
                chains, too.  Luckily, the lookahead doesn't have to be
                very big for chains j&gt;=1  <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.  <br>
                - 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...<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.  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.<br>
                <br>
                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...<br>
                <br>
                -Alan<br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <div>On 06/20/2013 03:32 AM, Mike Hearn wrote:<br>
                </div>
                <blockquote 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>&gt; BIP 32 already specifies how to use
                          the first three tree levels:  M/i/j/k,<br>
                          &gt; i~wallet, j~Internal/External, k~address.
                           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.  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.  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><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!  A
                        single-wallet<br>
                        implementation treats this merely as an
                        address-generation algorithm, and<br>
                        does not expose any hierarchy to the user
                        interface.  The user just<br>
                        “magically” 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><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.   If I don't want that, I<br>
                        <div>&gt; use your method.  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>
                           ParentPubKey: Public key of m/i' -- 33 bytes<br>
                           Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes<br>
                           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.  The ParentPubKey is a common
                        value across multiple services,<br>
                        corresponding to user's identity rooted in
                        [m/i'].  Each service gets their<br>
                        own 'j'.  ParentPubKey + Addend gives you the
                        PubKey of [m/i'/j].  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>
                          <div><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"
                              target="_blank">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></fieldset>
                  <br>
                  <pre>------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

<a moz-do-not-send="true" href="http://p.sf.net/sfu/windows-dev2dev" target="_blank">http://p.sf.net/sfu/windows-dev2dev</a></pre>
                  <br>
                  <fieldset></fieldset>
                  <br>
                  <pre>_______________________________________________
Bitcoin-development mailing list
<a moz-do-not-send="true" href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a>
<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>
</pre>
                </blockquote>
                <br>
              </blockquote>
              <br>
            </div>
            <br>
------------------------------------------------------------------------------<br>
            Get 100% visibility into Java/.NET code with AppDynamics
            Lite!<br>
            It's a free troubleshooting tool designed for production.<br>
            Get down to code-level detail for bottlenecks, with &lt;2%
            overhead.<br>
            Download for free and get started troubleshooting in
            minutes.<br>
            <a moz-do-not-send="true"
href="http://pubads.g.doubleclick.net/gampad/clk?id=48897031&amp;iu=/4140/ostg.clktrk"
              target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=48897031&amp;iu=/4140/ostg.clktrk</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>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------050803000509070405080005--