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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W2p3Q-0008HG-O8 for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 21:28:16 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W2p3P-00079y-Rd for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 21:28:16 +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 s0DLRvvs056961; Mon, 13 Jan 2014 21:27:57 GMT Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0DLRrwR031780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 21:27:56 GMT Date: Mon, 13 Jan 2014 16:27:52 -0500 From: Peter Todd To: Alan Reiner Message-ID: <20140113212752.GA9098@petertodd.org> References: <20140113194049.GJ38964@giles.gnomon.org.uk> <52D4458C.6010909@gmail.com> <20140113201407.GB7941@petertodd.org> <52D44F86.1040407@gmail.com> <20140113210217.GO38964@giles.gnomon.org.uk> <52D45755.60402@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <52D45755.60402@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 91866da5-7c99-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwEUElQaAgsB AmIbWVVeUlp7XGU7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQhx1 enxcFXtydARBcH4+ ZEViXXYVVUVyc0Ap E0tJEj4PbHphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJSIx ThQeHX0GEUEfSj4o IgdO X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/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: 1W2p3P-00079y-Rd 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: Mon, 13 Jan 2014 21:28:16 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote: > > I don't know if stealth addresses are the best solution to address > > this use case, but AFAIK the only current solution to this use case is > > to store a long-lived Bitcoin address in the addresss book. > > > > roy > > >=20 > Fair enough. I haven't spent much time thinking about that use case.=20 > Though, I question the feasibility of anything that requires O(N) EC > multiply operations/sec, where N is the total volume of transactions > moving over the network. But I guess if the prefix is big enough, the > scanning operations will remain feasible forever. Well that's the thing: the cost to find all stealth-address-using payments to you isn't O(n) transaction volume, it's O(n) anonymity set size. I think we can make a pretty good argument that the anonymity set people need is mostly fixed in size and has nothing to do with overall tx volume, so really we've got O(1) scaling. There is a catch however: if you need the prefix to be against H(scriptPubKey) rather than scriptPubKey directly the sender needs to grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that grinding can be done with hash operations rather than ECC - even if we needed 32-bit prefixes eventually computing 32-bit hash collisions is plausible, and more reasonable 8-bit is quite doable now. --=20 'peter'[:-1]@petertodd.org 00000000000000013f56c73dbb82447ba01e303648109b2e7ea0adf6ca53a7ff --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJS1FpYAAoJEBmcgzuo5/CF+AAIALfGJF/uIYAirWaoBBdJb1vF i2W8gb5itjg9keCLvj7y1jdTq2inDA5CArPUlRoWEm56UAt1mGw7sbQQomPDJKlw 0N8xp//JlKLCXEdZqFgBGqx9BS7Akoihsu6zQEgtX7UbeoypnxbgMc0QJOdgfosy hkYz38iUOCt0jBitQckKbbSniuGzAhjh41E/Tmv/pXxVJL734dIZvqlOBAsWEx1n +qF7lQpcMJ1zE4u2CITN0AYxQZ7DRPsAiqKS8+wBx+fW0MaGWNcJM5OnDlu6wTcQ tZHV8hVSwZhgYw3vssBlNG9HpZ5dvFm8oj8XY/R/UpE+bWRCObzXaIFHi2JKde0= =BZgv -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--