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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1W4NwT-0001Zq-4L
for bitcoin-development@lists.sourceforge.net;
Sat, 18 Jan 2014 04:55:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.173 as permitted sender)
client-ip=209.85.216.173; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f173.google.com;
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W4NwS-0000oj-6S
for bitcoin-development@lists.sourceforge.net;
Sat, 18 Jan 2014 04:55:33 +0000
Received: by mail-qc0-f173.google.com with SMTP id i8so4308661qcq.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 17 Jan 2014 20:55:26 -0800 (PST)
X-Received: by 10.224.60.69 with SMTP id o5mr9374406qah.92.1390020926727;
Fri, 17 Jan 2014 20:55:26 -0800 (PST)
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 w8sm16908591qag.15.2014.01.17.20.55.25
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 17 Jan 2014 20:55:26 -0800 (PST)
Message-ID: <52DA093D.4070505@gmail.com>
Date: Fri, 17 Jan 2014 23:55:25 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP1KAVhi_-cxCYe0rR9LUSYJ8MyW8=6eSJZ65FeY5ZJNuQ@mail.gmail.com> <20140114225321.GT38964@giles.gnomon.org.uk> <CANAnSg0tH_bK_19rsRRHOeZgrGYeWMhW89fXPyS4DQGmS4r_7A@mail.gmail.com> <CALimQCXgc0eXeOcqFGUaCpSF7gKEe87KzvLqHZwUysV3WyjjGw@mail.gmail.com> <CAAS2fgShChAQryfUOBp60jB-zxn2tH986fu1HfT+LsNdBYnoYg@mail.gmail.com> <CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com> <op.w9q6jdsayldrnw@laptop-air.hsd1.ca.comcast.net> <20140116212805.GA4421@petertodd.org> <CANAnSg2TY7Zh7RnHkBeTz1s-WutGLayum8q5DhdLhtOBMDT9ng@mail.gmail.com> <CANEZrP1=PMiJn9BoN50K1wz2tOdxx5L80ngjErCJqj5wm2ESPA@mail.gmail.com> <20140117144601.GA8614@petertodd.org>
<CALimQCU10asn65q=+VwCVNtgbROu9XQOYKzB7jy-TCFoemjEOQ@mail.gmail.com>
In-Reply-To: <CALimQCU10asn65q=+VwCVNtgbROu9XQOYKzB7jy-TCFoemjEOQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------000009010600060708060400"
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: 1W4NwS-0000oj-6S
Subject: Re: [Bitcoin-development] Stealth Addresses
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: Sat, 18 Jan 2014 04:55:33 -0000
This is a multi-part message in MIME format.
--------------000009010600060708060400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*
Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead? Then we don't need any ephemeral keys. We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver). When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.
Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.
Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here. But with this, we are not tied to
any particular crypto. Isn't there a much faster asymmetric scheme that
we can use? I've heard people talk about ed25519, though I'm not sure
it can be used for encryption. I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.
Here's how I envision it:
--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it. He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:]. Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y. He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message.
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key. If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier. If it doesn't, it's irrelevant to her
and she moves on.
[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]
Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)? But it all depends on having
fast asymmetric encryption.
-Alan
--------------000009010600060708060400
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 bgcolor="#FFFFFF" text="#000000">
*Avoiding ECDH calcs on every blockchain transaction (and avoiding
the prefix thing):*<br>
<br>
Can we skip the whole ECDSA/ECDH thing, and use the second key pair
for encryption instead? Then we don't need any ephemeral keys. We
use the much simpler scheme like I mentioned before (just root keys
and multpliers), but instead of requesting a multiplier from the
person receiving the money, the payer can create their own
multiplier and encrypt it into an OP_RETURN msg (using the secondary
public key of the receiver). When they do this, they append a
deterministic identifier to it, so that the receiver can immediately
identify it upon decryption.<br>
<br>
Basically, the receiver simply attempts decryption of every
OP_RETURN message, and if the identifier is there, they immediately
know that the tx is theirs, and that the other bytes of the
decrypted message is the multiplier used.<br>
<br>
Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than
the ECDH we've already talked about here. But with this, we are not
tied to any particular crypto. Isn't there a much faster asymmetric
scheme that we can use? I've heard people talk about ed25519,
though I'm not sure it can be used for encryption. I'd bet money
there is an asymmetric <u><i>encryption</i></u><i> </i>algorithm
that would be fast enough to not burden the receiver.<br>
<br>
Here's how I envision it:<br>
<br>
--Alice gives out her business card that has public key X (BIP32
root), and public key Y (fastCrypto)<br>
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's
public key by it. He prepares a transaction sending coins to that
address (Z)<br>
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX
|| addrZ)[8:]. Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y. He puts that
message in the OP_RETURN output.<br>
--Alice's wallet will attempt decryption of every OP_RETURN
message. First she computes hash(pubKeyX, addrZ)[8:], and then
decrypts the message with the fastCrypto private key. If the tx is
actually hers, the last 8 bytes will match the identifier, and she
knows to use the other 32 bytes as a multiplier. If it doesn't,
it's irrelevant to her and she moves on.<br>
<br>
[**Should probably use 24-byte values for the multipliers (or hashes
of 24-byte values), so that adding 8 bytes makes the whole message
an even 32 bytes which is better for encryption]<br>
<br>
Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)? But it all depends on
having fast asymmetric encryption.<br>
<br>
-Alan<br>
<br>
<br>
<br>
</body>
</html>
--------------000009010600060708060400--
|
