public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32
Date: Tue, 4 Dec 2012 22:50:17 -0500	[thread overview]
Message-ID: <CAAS2fgRfAJhqhgxRzZ6fyBdOBCGtTb5OXJO0gEbTry8KxvXvCg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgSvEy9qgyEgWui1Z_qD+qbRH3=CqY+ZJu6ki1T=kxB6-Q@mail.gmail.com>

On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd <wbl@uchicago.edu> wrote:
> being able to spend
> a coin sent to an address generated by this scheme implies being able
> to spend any coin generated
> by this scheme.

If you have the the full extended secret there then you can spend
along the chain— but just the plain ecdsa secret by itself is not
enough to spend anything but that address itself.

Or have I misunderstood you here?

> The easiest deterministic wallet construction is simply to use a
> stream cipher to generate random
> bytes used as the private keys in a wallet. Hierarchical constructions
> do not seem to me to add more,
> other then distinguishing transactions by sending to unique addresses,
> which could be done by other means.

Sadly that construction has no ability to separate address generation
from spending— an important element for merchant applications.  Not
just for their own own distinguishing of transactions but because the
use of fresh addresses is essential to the limited privacy properties
of the Bitcoin system.

I called that a type-1 deterministic wallet in some old forum post
where I wrote about the different derivation schemes as opposed to the
point combining type-2 construction. The hope in BIP32 was that we
could get away just using a single one.



      parent reply	other threads:[~2012-12-05  3:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05  3:06 [Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32 Mike Koss
2012-12-05  3:23 ` Gregory Maxwell
2012-12-05  3:36   ` Watson Ladd
     [not found]     ` <CAAS2fgSvEy9qgyEgWui1Z_qD+qbRH3=CqY+ZJu6ki1T=kxB6-Q@mail.gmail.com>
2012-12-05  3:50       ` Gregory Maxwell [this message]

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=CAAS2fgRfAJhqhgxRzZ6fyBdOBCGtTb5OXJO0gEbTry8KxvXvCg@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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