1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Tg60H-0004sh-Es
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Dec 2012 03:50:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.174 as permitted sender)
client-ip=209.85.223.174; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f174.google.com;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tg606-0000Sc-PV
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Dec 2012 03:50:33 +0000
Received: by mail-ie0-f174.google.com with SMTP id c11so7427943ieb.19
for <bitcoin-development@lists.sourceforge.net>;
Tue, 04 Dec 2012 19:50:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.178.8 with SMTP id cu8mr609895igc.5.1354679417541; Tue, 04
Dec 2012 19:50:17 -0800 (PST)
Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 19:50:17 -0800 (PST)
In-Reply-To: <CAAS2fgSvEy9qgyEgWui1Z_qD+qbRH3=CqY+ZJu6ki1T=kxB6-Q@mail.gmail.com>
References: <CAErK2CgWFarfs1WhGHs2L0b6ZuqCMhu72+dLNj0EZ1vN8=Au=g@mail.gmail.com>
<CAAS2fgQxQEAtspRQixU7KAqhcXYnev=20-hbDpMCO9nTEKT+RQ@mail.gmail.com>
<CACsn0cnwyWL2NL9eEboxqgTS-h5MS+LHajKOYpFiCXCBs6pLug@mail.gmail.com>
<CAAS2fgSvEy9qgyEgWui1Z_qD+qbRH3=CqY+ZJu6ki1T=kxB6-Q@mail.gmail.com>
Date: Tue, 4 Dec 2012 22:50:17 -0500
Message-ID: <CAAS2fgRfAJhqhgxRzZ6fyBdOBCGtTb5OXJO0gEbTry8KxvXvCg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.2 (/)
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
(gmaxwell[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1Tg606-0000Sc-PV
Subject: [Bitcoin-development] String-based Hierarchical Deterministic Keys
- Alternative to BIP 32
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: Wed, 05 Dec 2012 03:50:33 -0000
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=E2=80=94 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=E2=80=94 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.
|
