Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.176 as permitted sender)
	client-ip=209.85.223.176; envelope-from=etotheipi@gmail.com;
	helo=mail-ie0-f176.google.com; 
Message-ID: <51CB08EE.1050403@gmail.com>
Date: Wed, 26 Jun 2013 11:29:50 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
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>
In-Reply-To: <CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------040906020302010007090602"
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
 - Payment Protocol
Precedence: list

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

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


--------------040906020302010007090602
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">
    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 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 class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a 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>
  </body>
</html>

--------------040906020302010007090602--