summaryrefslogtreecommitdiff
path: root/38/5542934aa72e2f29bd8dead6707536a48a97b3
blob: e2e65b5f8702673ea0ee6774ed6eaeaf826f8b19 (plain)
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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jeremy@taplink.co>) id 1UpVwy-0000Kf-RE
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Jun 2013 03:54:20 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1UpVwx-0003AG-RM for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Jun 2013 03:54:20 +0000
Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ;
	Wed, 19 Jun 2013 20:54:42 -0700
Message-ID: <9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
From: "Jeremy Spilman" <jeremy@taplink.co>
To: <bitcoin-development@lists.sourceforge.net>
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
	<51C21035.9080407@gmail.com>
	<53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
	<51C234FA.5030909@gmail.com>
In-Reply-To: <51C234FA.5030909@gmail.com>
Date: Wed, 19 Jun 2013 20:54:18 -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: 1UpVwx-0003AG-RM
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: Thu, 20 Jun 2013 03:54:21 -0000

> 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