From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W0qG0-0007J4-Pv for bitcoin-development@lists.sourceforge.net; Wed, 08 Jan 2014 10:21:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1W0qFz-0007HE-Pq for bitcoin-development@lists.sourceforge.net; Wed, 08 Jan 2014 10:21:04 +0000 Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by mail.taplink.co ; Wed, 8 Jan 2014 02:27:34 -0800 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: bitcoin-development@lists.sourceforge.net, "Peter Todd" References: <20140106120338.GA14918@savin> Date: Wed, 08 Jan 2014 02:20:57 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Jeremy Spilman" Organization: TapLink Message-ID: In-Reply-To: <20140106120338.GA14918@savin> User-Agent: Opera Mail/1.0 (Win32) oclient: 192.168.168.135#jeremy@taplink.co#465 X-Spam-Score: -1.7 (-) 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 -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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: 1W0qFz-0007HE-Pq 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: Wed, 08 Jan 2014 10:21:05 -0000 Thanks Peter for the paper! I'm just going to restate your 'simple explanation' to make sure I got it... The payee publishes a public key of theirs, which will be a long-standing identifier, public key = 'Q', corresponding private key = 'd'. To pay them, payee generate a keypair, private key = 'e' public key of 'P'. Publish 'P' in the transaction. The payer can calculate S = eQ, where S is a shared secret between payer/payee. The payee calculates the same S as S = dP. So the payee sees 'P' in a transaction, and multiplies by their private key, to get S. 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' = H(S) + Q, does this mean Q + SHA256(33-byte S)? A payee has to check each transaction (or every transaction of a fixed prefix) with 'P', calculate Q' = 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). 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." Hope I got that right... On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd wrote: > Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared > secret that the payee can use to recover their funds. Let the payee have > keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to > arrive at shared secret c=H(eQ)=H(dP). This secret could be used to > derive a ECC secret key, and from that a scriptPubKey, however that > would allow both payor and payee the ability to spend the funds. So > instead we use BIP32-style derivation to create Q'=(Q+c)G and associated > scriptPubKey. > > As for the nonce keypair, that is included in the transaction in an > additional zero-valued output: > RETURN