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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1UpQOH-000251-9x
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 21:58:09 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1UpQOG-00021h-Ej for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 21:58:09 +0000
Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ;
Wed, 19 Jun 2013 14:58:33 -0700
Message-ID: <53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
<51C21035.9080407@gmail.com>
In-Reply-To: <51C21035.9080407@gmail.com>
Date: Wed, 19 Jun 2013 14:58:06 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
oclient: 192.168.168.158#jeremy@taplink.co#465
X-Spam-Score: -2.7 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UpQOG-00021h-Ej
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
- Payment Protocol
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, 19 Jun 2013 21:58:09 -0000
Hi Alan,
> “BIP 32 does not prescribe a way to use multiple chains like you described
> with the convenient type-2 derivation (though we could create a variant
> that does)”
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
and then generally expects transactions to come in starting at /0 and
incrementing monotonically.
Also, I'm not sure I follow your point about the 128kB hardware wallet --
it's a signing device, so assuming it's even validating output amounts, at
worst it cares about the number of inputs to the outputs being spent, but in
many cases you're just handing it a sighash and the BIP32 "path"
(/1/54/27/0) to generate the right private key for signing. The hardware
wallet is not actually listening on the P2P network and detecting payments,
so it's unaffected by dedicating child-nodes to each contact.
Consider the benefits of gaining critical mass of support for a technique
which [I think] can be used in all cases, and increases security and privacy
for everyone. I think there are huge benefits to leaving the age of 'single
address generation' behind us...
Thanks,
--Jeremy
|
