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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W2nqj-0003ce-J4 for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 20:11:05 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f47.google.com; Received: from mail-la0-f47.google.com ([209.85.215.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W2nqh-0003me-Og for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 20:11:05 +0000 Received: by mail-la0-f47.google.com with SMTP id eh20so3322485lab.6 for ; Mon, 13 Jan 2014 12:10:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.167.103 with SMTP id zn7mr559719lab.68.1389643856980; Mon, 13 Jan 2014 12:10:56 -0800 (PST) Received: by 10.112.198.65 with HTTP; Mon, 13 Jan 2014 12:10:56 -0800 (PST) In-Reply-To: <52D4458C.6010909@gmail.com> References: <20140106120338.GA14918@savin> <20140110102037.GB25749@savin> <20140113194049.GJ38964@giles.gnomon.org.uk> <52D4458C.6010909@gmail.com> Date: Mon, 13 Jan 2014 12:10:56 -0800 Message-ID: From: Gregory Maxwell To: Alan Reiner Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1W2nqh-0003me-Og Cc: Bitcoin Development 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: Mon, 13 Jan 2014 20:11:05 -0000 On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner wrote: > Then when someone > wants to pay you, you simply give them the multiplier and root key (they > already have the root key, but should verify). [...] > What > advantages does "stealth addresses" have over this scheme? You could extend > it using some kind of deterministic sub-branching and/or ECDH to create > multiple payment addresses without querying the payee. The stealth address stuff is the ECDH to create multiple payment addresses without querying the payee. Uh while I'm responding again, what I'd discussed with Peter Todd in IRC used two EC points in the stealth address. One for the payment and one for the ECDH. The reason to use two is that it makes delegating detection possible and so you don't have to have you spending keys online to even detect these payments. Why'd that get dropped? I don't think this is a good idea if you have to constantly keep your spending key(s) online even to detect payments, even with the limited use-cases envisioned.