summaryrefslogtreecommitdiff
path: root/59/0d869773f19c70cf6f828f0dfe4f20f029092d
blob: 5f412c5337a77e67afffc28109b87fc39cee46fe (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1W1ZCw-0007rM-Jv
	for bitcoin-development@lists.sourceforge.net;
	Fri, 10 Jan 2014 10:20:54 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1W1ZCt-00064T-6W for bitcoin-development@lists.sourceforge.net;
	Fri, 10 Jan 2014 10:20:54 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0AAKjcs069907;
	Fri, 10 Jan 2014 10:20:45 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 s0AAKbbG087762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 10 Jan 2014 10:20:40 GMT
Date: Fri, 10 Jan 2014 05:20:37 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140110102037.GB25749@savin>
References: <20140106120338.GA14918@savin>
	<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK"
Content-Disposition: inline
In-Reply-To: <op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: db4bd7e4-79e0-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwIUElQaAgsB AmIbWlReUl17XWI7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrAW1w fUxMJRl6cAJAejBx ZEBlXj4PDkAoIUEo
	RlNTHDgGeGZhPWMC 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: 1W1ZCt-00064T-6W
Cc: 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: Fri, 10 Jan 2014 10:20:54 -0000


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

On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
> Thanks Peter for the paper!
>=20
> I'm just going to restate your 'simple explanation' to make sure I
> got it...
>=20
> The payee publishes a public key of theirs, which will be a
> long-standing identifier, public key =3D 'Q', corresponding private
> key =3D 'd'.
>=20
> To pay them, payee generate a keypair, private key =3D 'e' public key
> of 'P'. Publish 'P' in the transaction.
>=20
> The payer can calculate S =3D eQ, where S is a shared secret between
> payer/payee. The payee calculates the same S as S =3D dP. So the payee
> sees 'P' in a transaction, and multiplies by their private key, to
> get S.
>=20
> Now that we have the shared secret, either side can calculate an
> offset to Q which becomes the pay-to-address. When you say
> BIP32-style derivation, Q' =3D H(S) + Q, does this mean Q +
> SHA256(33-byte S)?

I think that's correct, but my ECC math is a bit shakey... In any case,
what's important is that you can derive a pubkey such that only the
recipient has the privkey, and without knowledge of the shared secret
you can't determine what the recipients master pubkey was.

> A payee has to check each transaction (or every transaction of a
> fixed prefix) with 'P', calculate Q' =3D Q + H(dP) and see if that
> transaction pays to Q'. If the address matches, then the payee can
> spend it with private key of d + H(dP).

Yup, you're understanding matches mine. (no guarantee if my
understanding is correct!)

> One downside is that you have to hold your private key in memory
> unencrypted in order to identify new payments coming in. So
> stealth-addresses may not be suitable for receiving eCommerce
> payments, since you can't implement a corresponding watch-only
> wallet, e.g. there's no way to "direct-deposit into cold storage."

Oh, sorry, I forgot to mention it in my first write-up but you can
easily make stealth addresses include a second pubkey for the purpose of
the communication that either isn't used in the scriptPubKey at all, or
is part of a n-of-m multisig. (n>=3D2) Interestingly that also means you
can give a third-party that key and out-source the effort of scanning
the blockchain for you.

--=20
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

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

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

iQGrBAEBCACVBQJSz8l1XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDI4YTVjOWVkYWJjOTY5N2ZlOTY0MDVmNjY3YmUxZDZkNTU4
ZDFkYjIxZDQ5Yjg4NTcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsonAf/US5/bYqaNR9t0LdbcesaxkGS
j0nxcCZMJmFEs36c5XnxrppGv5i930cPOcVcPEELiJ5wbkMQfq+M805/mViek2Mx
fkhV5YD4Ol3ZQUm5gYSCeCyeIuYBZNlpznufFj6IDFHlXF0nBWkZBA3eh5tQwGWF
1w9TpkBO9TzEQNRgJiAsQnRid8b8VnF2fvUgK0nVCRVxYzGgofniBjmhuoju3gNF
d46l9MP5h6tyuAdXPIMvSfAO9KWVYawneELU7AVLKCHoo5xQeBnkOmoI4KBaMjv8
U5NyCi96GvqmUzTORIlwG2Qplg0JLWuZYd6Aedia4vX95QzjUl2kXTHgpoVwdA==
=x2J6
-----END PGP SIGNATURE-----

--/NkBOFFp2J2Af1nK--