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 1W6ctV-0004px-Tc for bitcoin-development@lists.sourceforge.net; Fri, 24 Jan 2014 09:17:45 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.55 as permitted sender) client-ip=62.13.149.55; envelope-from=pete@petertodd.org; helo=outmail149055.authsmtp.co.uk; Received: from outmail149055.authsmtp.co.uk ([62.13.149.55]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W6ctU-0008W1-Id for bitcoin-development@lists.sourceforge.net; Fri, 24 Jan 2014 09:17:45 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0O9Hbo8031773; Fri, 24 Jan 2014 09:17:37 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 s0O9HX6g012048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Jan 2014 09:17:36 GMT Date: Fri, 24 Jan 2014 04:17:33 -0500 From: Peter Todd To: Jeremy Spilman Message-ID: <20140124091733.GC15398@savin> References: <20140114225321.GT38964@giles.gnomon.org.uk> <20140115230901.GA25135@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 5d9fb454-84d8-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAYUElQaAgsB AmIbW11eUVp7WmU7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAWMI fnYYBRlzdQVCcDBx bEBkWj5eCE0sJ0J4 RlNcETkOeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4WGDo9 QRkBFzEiVVYZTjky JFQvJlIGEV0KZQ18 eUA5RxcAKR4MAwZP fQkNOiILb2IdSiMv EQMSdEISCjBGWipH Q3UA 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: 1W6ctU-0008W1-Id Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: 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: Fri, 24 Jan 2014 09:17:46 -0000 --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote: > Let's say the payee's reusable address is ' = =20 > ...', where is 2 bytes. Without any length indicator. What's the= =20 > payer going to put on the blockchain? How would they know what the 'rest = =20 > of the space' is? They would have to put the whole verbatim into= =20 > the OP_RETURN without knowing how many bits of the payee actuall= y =20 > wants to see there. >=20 > If instead, the address is ' ...'= =20 > where is 2 bytes, and is 1 byte, representing number= =20 > of bits of prefix that should be fixed. >=20 > Then payer will know how much of from the address should be take= n =20 > verbatim, and the rest of the two bytes would be replaced with random =20 > data, and exactly two bytes would be put in the OP_RETURN. >=20 > If was zero, the 2 byte prefix in the reusable address must b= e =20 > ignored, and an entirely random 2 byte prefix would be put into the =20 > OP_RETURN. >=20 > I'm a bit worried about broken implementations copying the from = =20 > the reusable address into OP_RETURN when is 0, and ending up = =20 > basically identifying the payee. That's the only reason I can think of to= =20 > make ' ' optional in the reusable address, to prevent = =20 > the opportunity to screw it up. You would *still* put a 2-byte random =20 > prefix in the OP_RETURN, even if the fields weren't in the address at all= =2E =20 > It's just a minor concern though. Something to keep in mind is that it's quite likely that the indexes available will be over H(scriptPubKey). There's really good engineering reasons for doing this: you need to be able to create succinct proofs of fraud in indexes, miner committed and otherwise, and the only way they are succinct is if you limit the length. Hashes naturally do that because it's so expensive to generate partial collisions. If you don't do this on the other hand now you have a situation where the usual case - max 16 level deep tree - and worst case - hundreds or even thousands of levels deep - are vastly different. That's hard to test for and likely to reveal implementation-specific limits in nasty ways. Anyway, grinding nonces isn't much of a burden given it's fast hash functions. The prefixes in question are fairly small and will be small for the forseeable future. As I said elsewhere in this thread, even Javascript has performance that's perfectly adequate for the task. --=20 'peter'[:-1]@petertodd.org 00000000000000003590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJS4i+tXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAzNTkwYThhMjBlYzlmZjViMWMxYWYzZjA0NmExZjYyZGMx YWM5YTQ2NDcyMWZkOGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuODQf/ZHgdMxjVeCr13gSt4ov/fv8q s1J9qdsDHc1jner0U56iKa6Qs62hXPlV0tJIBFI1Dh2lAVWNb+nUi1pSiJQS2GwO UES95YdSp66rL6Ssq/wVgGLMcefzwhc9Bc8g8FKJSOBbpDOaUk/k7+PIo9DIENlT KmUH4Uy9X63BeIde6OTccCtUWysTb8rxH6TS8UVV9iDGEUyy+BXiMjZNhdI9OqFB pZ7opCSPPjWtpJWmaLwk/SBDhTTuzZ/4z+Zf0UX5aRwub2FpYAHupK1Y2l4EewvC uy601CQI7r7nRhLn5ApN1a9AS199zFbxLlMwwFtJraZS/LkSxXJ3RdlndZJ1Dw== =jTX+ -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C--