Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbTRF-0005Ka-JR for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 08:46:45 +0000 X-ACL-Warn: Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] helo=cavuit01.kulnet.kuleuven.be) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RbTRE-0001bh-Dn for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 08:46:45 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 0CA6C138094.A971C X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 0CA6C138094 for ; Fri, 16 Dec 2011 09:46:34 +0100 (CET) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps02.kuleuven.be (Postfix) with ESMTP id 908C2F3864 for ; Fri, 16 Dec 2011 09:46:33 +0100 (CET) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id C522E10052 for ; Fri, 16 Dec 2011 10:46:57 +0100 (CET) Received: by wop.ulyssis.org (Postfix, from userid 615) id CB09687C1AB; Fri, 16 Dec 2011 09:46:33 +0100 (CET) Date: Fri, 16 Dec 2011 09:46:33 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: bitcoin-development@lists.sourceforge.net Message-ID: <20111216084631.GB20470@ulyssis.org> References: <1323929094.37881.YahooMailClassic@web120902.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1RbTRE-0001bh-Dn Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 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, 16 Dec 2011 08:46:45 -0000 On Thu, Dec 15, 2011 at 04:26:38PM +0800, Walter Stanish wrote: > Interaction is a requirement, since there seems to be a widely felt > need to preserve anonymity through the use of temporary addresses. > Generating a temporary address requires some actual processing to > achieve, since the issuing of the new address cannot be done without > interacting with the entity hosting the wallet (unless I'm missing > something?). Just replying to this one comment: yes, some interaction is always necessary, but not necessarily directly with the entity hosting the wallet. There are some EC crypto tricks to do this (often mentioned under "deterministic wallets" before): The wallet-hosting entity has a private key x, with public key X. The address-generating entity knows X, and generates a fresh private key y for each transaction. For each, it calculates Z=y*X, and asks the client to pay to hash160(Z). Afterwards, it can send a bunch of y's to the wallet hosting service, which can reconstruct z=y*x for each. Alternatively, the y's can be generated according to a predefined scheme instead. -- Pieter