From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Jeremy Spilman Message-ID: <20140110102037.GB25749@savin> References: <20140106120338.GA14918@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--