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
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
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 <etotheipi@gmail.com>) id 1UpNco-0002Ep-H8
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 19:00:58 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.173 as permitted sender)
client-ip=209.85.223.173; envelope-from=etotheipi@gmail.com;
helo=mail-ie0-f173.google.com;
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UpNcn-0000dT-Il
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Jun 2013 19:00:58 +0000
Received: by mail-ie0-f173.google.com with SMTP id k13so14330599iea.32
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Jun 2013 12:00:52 -0700 (PDT)
X-Received: by 10.50.136.230 with SMTP id qd6mr2053027igb.4.1371668452227;
Wed, 19 Jun 2013 12:00:52 -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 ir8sm7396363igb.6.2013.06.19.12.00.51
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 19 Jun 2013 12:00:51 -0700 (PDT)
Message-ID: <51C1FFDA.1050308@gmail.com>
Date: Wed, 19 Jun 2013 15:00:42 -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: Adam Back <adam@cypherspace.org>
References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch>
<51C1C288.4000305@gmail.com>
<20130619152815.GA14729@netbook.cypherspace.org>
<20130619183657.GA16708@netbook.cypherspace.org>
In-Reply-To: <20130619183657.GA16708@netbook.cypherspace.org>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------050302010302050007010608"
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: 1UpNcn-0000dT-Il
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 19:00:58 -0000
This is a multi-part message in MIME format.
--------------050302010302050007010608
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 06/19/2013 02:36 PM, Adam Back wrote:
> This maybe simpler and trivially compatible with existing type2 public
> keys
> (ones that are multiples of a parent public key): send an ECDSA
> signature of
> the multiplier, and as we know you can compute ("recover") the parent
> public
> key from an the ECDSA signature made using it.
>
> Adam
>
> On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
>> [q-th root with unknown no discrete log artefact]
>>
>> If it was a concern I guess you could require a proof of knowledge of
>> discrete log. ie as well as public key parent, multiplier the
>> address must
>> include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
>> knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The "observer wallet" should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
--------------050302010302050007010608
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">
On 06/19/2013 02:36 PM, Adam Back wrote:<br>
<blockquote
cite="mid:20130619183657.GA16708@netbook.cypherspace.org"
type="cite">This maybe simpler and trivially compatible with
existing type2 public keys
<br>
(ones that are multiples of a parent public key): send an ECDSA
signature of
<br>
the multiplier, and as we know you can compute ("recover") the
parent public
<br>
key from an the ECDSA signature made using it.
<br>
<br>
Adam
<br>
<br>
On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
<br>
<blockquote type="cite">[q-th root with unknown no discrete log
artefact]
<br>
<br>
If it was a concern I guess you could require a proof of
knowledge of
<br>
discrete log. ie as well as public key parent, multiplier the
address must
<br>
include ECDSA sig or Schnorr proof of knowledge (which both
demonstrate
<br>
knowledge of the discrete log of Q to base G.)
<br>
</blockquote>
</blockquote>
<br>
It's a cool trick but requiring a signature on each multiplier
defeats one of the purposes of a deterministic wallet. I don't want
to have to explicitly export a whole bunch of signatures from my
offline system just to exercise this address option. The "observer
wallet" should be able to do anything it needs to on its own,
without help from the offline wallet. <br>
<br>
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that <i>someone</i>
owns that private key, you could send {Sign(MagicString),
Multiplier}. So it becomes one signature operation <b>per wallet</b>,
but creating new wallets would require going back to the offline
computer for that one-time signature. That's better than the
alternative, but it's still extra bloat for the wallet apps.<br>
<br>
Either way, I'm not convinced that these are a problem for the
specified use cases I outlined. In cases where you have a
persistent business relationship, they need to verify the parent
public key exchange anyway. After that, the software doesn't
technically require the transmission of the PubKey, it only needs
the Name/ID of the party and the multiplier and it will fetch the
PubKey from its data store. Or it is transmitted and the payer
verifies it's correct. Computing an alternate {PubKey', Mult'} that
produces the same address and then using it in a MitM attack doesn't
work here if the two parties pre-verified the public keys. <br>
<br>
In the case that a business is checking whether the cashout address
of a customer is the same as the last time: if the first payout was
not replaced by an attacker, then the business already has the
correct public key in their DB and a replacement of further payout
requests will fail validation. If the first payout was replaced...
well that could've been done anyway (with or without this alternate
form), and the customer wouldn't have received their money and the
whole process would be flagged and terminated before further
transactions.<br>
<br>
-Alan<br>
<br>
<br>
</body>
</html>
--------------050302010302050007010608--
|
