summaryrefslogtreecommitdiff
path: root/f1/be4166d5a5c589947dde3bc6734337fef8d1dc
blob: 2028950b568795bf053f0d2084fbbe6f4085b27f (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
147
148
149
150
151
152
153
154
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1W5Ciy-0000sq-AL
	for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Jan 2014 11:09:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.81 as permitted sender)
	client-ip=62.13.149.81; envelope-from=pete@petertodd.org;
	helo=outmail149081.authsmtp.net; 
Received: from outmail149081.authsmtp.net ([62.13.149.81])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1W5Cix-0006Qc-4o for bitcoin-development@lists.sourceforge.net;
	Mon, 20 Jan 2014 11:09:00 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0KB8qHA080194;
	Mon, 20 Jan 2014 11:08:52 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0KB8lX5031805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 20 Jan 2014 11:08:49 GMT
Date: Mon, 20 Jan 2014 06:08:47 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140120110847.GF3468@savin>
References: <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>
	<52DA093D.4070505@gmail.com>
	<CAAS2fgSdLXfKgbC+MtsiXdp9o7BNp1pc1p_G511LrgwOzGNZFg@mail.gmail.com>
	<52F8B4EC-F955-46E4-B871-3BEEFF69907D@taplink.co>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="0hHDr/TIsw4o3iPK"
Content-Disposition: inline
In-Reply-To: <52F8B4EC-F955-46E4-B871-3BEEFF69907D@taplink.co>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3dad3ae0-81c3-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAIUElQaAgsB AmIbWlVeUFV7XGM7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrAWdz DkJ2Vxlxdg1GfTBx Y05rXD5YCBUudhco
	QlNcFD4FeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4wAjM1 QwwCVRwjEVcIXD4+ NHQA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1W5Cix-0006Qc-4o
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: Mon, 20 Jan 2014 11:09:00 -0000


--0hHDr/TIsw4o3iPK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
>=20
>=20
> > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrot=
e:
> >> Isn't there a much faster asymmetric scheme that we can use?  I've hea=
rd people talk about ed25519, though I'm not sure it can be used for encryp=
tion.
> >=20
> > Doing ECDH with our curve is within a factor of ~2 of the fastest
> > encryption available at this security level, AFAIK.  And separate
> > encryption would ~double the amount of data vs using the ephemeral key
> > for derivation.
> >=20
> > Using another cryptosystem would mandate carry around additional code
> > for a fast implementation of that cryptosystem, which wouldn't be
> > fantastic.
> >=20
> > So I'm not sure much can be improved there.
>=20
> In the case where payment is being sent only to Q1, and Q2 is for discove=
ry only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting i=
n 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication=
=2E=20
>=20
> 80-bits of security I assume still greatly exceeds the actual level of pr=
ivacy you get with the overall solution, and since Q2 is never protecting a=
ctual funds...
>=20
> But if it's a "real weakening" of the privacy then definitely not worth i=
t, and even the added complexity of another curve seems possibly not worth =
it...

Keep in mind that Bitmessage uses the same ECDH mechanism as what
stealth addresses will use. They seem to get decent enough performance
=66rom it for a use-case not-unlike that of a Bitcoin wallet.

In any case I'm interested in knowing actual performance numbers for it;
last I talked to Kyle Drake he said he was working on getting ECDH
numbers on Javascript, probably the slowest possible implementation of
the idea. As for send to stealth addresses using prefixes, he's
confirmed that you'll be able to do that will well under a second to
brute-force the prefixes with the proposed OP_RETURN mechanism even with
rather long 8-bit prefixes.

--=20
'peter'[:-1]@petertodd.org
000000000000000190a2900f1a25c507a999fa11116f7bd0126618c1ebc4f5fb

--0hHDr/TIsw4o3iPK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJS3QO+XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDE5MGEyOTAwZjFhMjVjNTA3YTk5OWZhMTExMTZmN2JkMDEy
NjYxOGMxZWJjNGY1ZmIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfujHAf+JNlRMEOUyH882IJWoVbW3E6M
kVvj9mhWeV3CyMba6zNzgoziGg0xcjBUgH8CQ3547GMqaEgzatacHNlGKXyvu49+
RBbGUfd2aUx5ktUEjU2R/49ZPweZ2Bik3dpK2ocqTAe03zPzTvdQk7+tFQnWu6iO
7FCatwD8qDX1gB0mQrIDcpf5lvjBTwc0f8XAP63Po7lWYBNxZUhji8mZxp8mQ/rT
QXpU9VihHjdUza+sAoKh5LR8kqAa5Wq4Bn17fOaa3iD69sgJuaNIzPUrtAwfm3YW
3SVzk1q+8DvUiEtpfznTa82xEYhBeW9j4yPPghvB2BqrQx/MeovOY/xOkdTv9w==
=omts
-----END PGP SIGNATURE-----

--0hHDr/TIsw4o3iPK--