diff options
| author | Peter Todd <pete@petertodd.org> | 2014-01-10 05:20:37 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-10 10:20:54 +0000 |
| commit | 34297e01706c83f2d426f247bd29aa406610dd0f (patch) | |
| tree | c0f6b7cdbc4d3cbd0af9cfca59ccc5c977b93f2b | |
| parent | 691e3a671aa93a55d87f2ce0d02438f2967724e2 (diff) | |
| download | pi-bitcoindev-34297e01706c83f2d426f247bd29aa406610dd0f.tar.gz pi-bitcoindev-34297e01706c83f2d426f247bd29aa406610dd0f.zip | |
Re: [Bitcoin-development] Stealth Addresses
| -rw-r--r-- | 59/0d869773f19c70cf6f828f0dfe4f20f029092d | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/59/0d869773f19c70cf6f828f0dfe4f20f029092d b/59/0d869773f19c70cf6f828f0dfe4f20f029092d new file mode 100644 index 000000000..5f412c533 --- /dev/null +++ b/59/0d869773f19c70cf6f828f0dfe4f20f029092d @@ -0,0 +1,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-- + + |