<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"><<a href="mailto:jeremy@taplink.co" target="_blank">jeremy@taplink.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> BIP 32 already specifies how to use the first three tree levels: M/i/j/k,<br>
> i~wallet, j~Internal/External, k~address. The first level is actually<br>
> type-1 derived, and thus we cannot create an arbitrary number of them<br>
> without pre-computing them from the offline wallet. So it's not "free" to<br>
> 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 <= j <= 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 > 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>
> 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 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>
> For instance, maybe there's a benefit to using the same parent pubkey<br>
</div>> across multiple services, as a form of identity. If I don't want that, I<br>
<div class="im">> 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 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 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 href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a 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>