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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UphQI-00008m-V1
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Jun 2013 16:09:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.41 as permitted sender)
client-ip=209.85.216.41; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f41.google.com;
Received: from mail-qa0-f41.google.com ([209.85.216.41])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UphQD-0006a5-3N
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Jun 2013 16:09:22 +0000
Received: by mail-qa0-f41.google.com with SMTP id f14so1222932qak.14
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Jun 2013 09:09:11 -0700 (PDT)
X-Received: by 10.49.71.70 with SMTP id s6mr1124799qeu.66.1371744551577;
Thu, 20 Jun 2013 09:09:11 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id j5sm1560691qan.7.2013.06.20.09.09.10
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 20 Jun 2013 09:09:10 -0700 (PDT)
Message-ID: <51C32926.10904@gmail.com>
Date: Thu, 20 Jun 2013 12:09:10 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch>
<51C1C288.4000305@gmail.com>
<20130619152815.GA14729@netbook.cypherspace.org>
<20130620074830.GA21724@crunch>
<66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR>
In-Reply-To: <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------060104010105000204080005"
X-Spam-Score: -0.6 (/)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1UphQD-0006a5-3N
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 16:09:23 -0000
This is a multi-part message in MIME format.
--------------060104010105000204080005
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> which could involve proving something to a third party that has not seen
>> the communication between payer and payee.
> OK - I think I follow now. So a third-party who does not see any of the
> communication between the payer and payee only knows the HASH160. Let's say
> the payee denies receipt of the funds....
>
> It's easy to prove what public key it was sent to (it's the preimage), but
> you can't prove the parent of that public key. You can provide any number of
> ParentPubKey * Multiplier that could have been used, so the 3rd party is
> unconvinced by a "matching" ParentPubKey * Multiplier.
>
> However, if you calculated the destination using: PubKeyParent *
> HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
> PubKeyParent and Multiplier (or Addend) that produces the destination
> address, you've proven the payment is in fact spendable by PubKeyParent, and
> they can't deny receipt. Very cool.
>
> Sorry for "echoing" this back, it took me a little while to work it out, so
> I thought I'd write it down. Hope I got it right...
>
> If you give {PubKey, ChainCode} you do get this feature. If you give
> {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
> having plausible deniability.
>
> If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
> could give HMAC(cpar, i) instead of Addend, and then you would get this
> feature; a way to 'skip down' a level in the wallet hierarchy, keep the
> 'chain of custody' so to speak back to the ParentPubKey intact, without
> having to disclose the ChainCode. Meh...
>
>
I agree, if we used Timo's suggestion, that seems to clean up the
remaining uncertainties with this recommendation. I'm not convinced
those uncertainties matter in this situation, where there is no question
about the parent public key. That is the part of the process that was
already verified, per my previous examples. But certainly, for this to
be more versatile it would need that.
If I modify my request to match Timo's recommendation, then it loses the
benefit of being a simple, non-disruptive extension of BIP 32. I'm not
fond of deviating from BIP 32, as it kind of defeats one of the benefits
of BIP 32: standardization. And I'm not inclined to make an
Armory-specific wallet variant.
But I can't tell if the benefits are lost on you, or you just don't
think they are worth it (or I'm overstating them). I'm strongly opposed
to bring extra wallets/chains into this equation /*just*/ to get a
benefit that can be had with a simple alternative encoding. This isn't
a question of which is better, it's a matter of recognizing that both
forms have usefulness and should both be supported.
-Alan
--------------060104010105000204080005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 06/20/2013 05:10 AM, Jeremy Spilman
wrote:<br>
</div>
<blockquote cite="mid:66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR"
type="cite">
<blockquote type="cite">
<pre wrap="">which could involve proving something to a third party that has not seen
the communication between payer and payee.
</pre>
</blockquote>
<pre wrap="">
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt of the funds....
It's easy to prove what public key it was sent to (it's the preimage), but
you can't prove the parent of that public key. You can provide any number of
ParentPubKey * Multiplier that could have been used, so the 3rd party is
unconvinced by a "matching" ParentPubKey * Multiplier.
However, if you calculated the destination using: PubKeyParent *
HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
PubKeyParent and Multiplier (or Addend) that produces the destination
address, you've proven the payment is in fact spendable by PubKeyParent, and
they can't deny receipt. Very cool.
Sorry for "echoing" this back, it took me a little while to work it out, so
I thought I'd write it down. Hope I got it right...
If you give {PubKey, ChainCode} you do get this feature. If you give
{ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
having plausible deniability.
If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
could give HMAC(cpar, i) instead of Addend, and then you would get this
feature; a way to 'skip down' a level in the wallet hierarchy, keep the
'chain of custody' so to speak back to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
</pre>
</blockquote>
<br>
I agree, if we used Timo's suggestion, that seems to clean up the
remaining uncertainties with this recommendation. I'm not
convinced those uncertainties matter in this situation, where there
is no question about the parent public key. That is the part of the
process that was already verified, per my previous examples. But
certainly, for this to be more versatile it would need that. <br>
<br>
If I modify my request to match Timo's recommendation, then it loses
the benefit of being a simple, non-disruptive extension of BIP 32.
I'm not fond of deviating from BIP 32, as it kind of defeats one of
the benefits of BIP 32: standardization. And I'm not inclined to
make an Armory-specific wallet variant.<br>
<br>
But I can't tell if the benefits are lost on you, or you just don't
think they are worth it (or I'm overstating them). I'm strongly
opposed to bring extra wallets/chains into this equation <i>*just*</i>
to get a benefit that can be had with a simple alternative
encoding. This isn't a question of which is better, it's a matter
of recognizing that both forms have usefulness and should both be
supported. <br>
<br>
-Alan<br>
</body>
</html>
--------------060104010105000204080005--
|
