From: Mike Hearn <mike@plan99•net>
To: Jeremy Spilman <jeremy@taplink•co>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Thu, 20 Jun 2013 09:32:22 +0200 [thread overview]
Message-ID: <CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com> (raw)
In-Reply-To: <9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
[-- Attachment #1: Type: text/plain, Size: 5430 bytes --]
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> 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
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 6613 bytes --]
next prev parent reply other threads:[~2013-06-20 7:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 19:29 Jeremy Spilman
2013-06-19 20:10 ` Alan Reiner
2013-06-19 21:58 ` Jeremy Spilman
2013-06-19 22:47 ` Alan Reiner
2013-06-20 3:54 ` Jeremy Spilman
2013-06-20 7:32 ` Mike Hearn [this message]
2013-06-26 15:29 ` Alan Reiner
2013-08-09 17:57 ` [Bitcoin-development] Optional "wallet-linkable" address format (Re-request) Alan Reiner
2013-08-09 19:58 ` Mike Hearn
2013-08-09 20:12 ` Alan Reiner
2013-08-09 20:35 ` Mike Hearn
2013-08-09 21:51 ` Gavin Andresen
-- strict thread matches above, loose matches on Subject: below --
2013-06-18 3:48 [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol Alan Reiner
2013-06-19 12:19 ` Melvin Carvalho
2013-06-19 13:37 ` Alan Reiner
2013-06-19 13:54 ` Pieter Wuille
2013-06-19 14:25 ` Timo Hanke
2013-06-19 14:39 ` Alan Reiner
2013-06-19 15:28 ` Adam Back
2013-06-19 18:36 ` Adam Back
2013-06-19 19:00 ` Alan Reiner
2013-06-20 7:48 ` Timo Hanke
2013-06-20 9:10 ` Jeremy Spilman
2013-06-20 16:09 ` Alan Reiner
2013-06-19 20:03 ` Timo Hanke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox