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; 
Date: Fri, 24 Jan 2014 04:17:33 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140124091733.GC15398@savin>
References: <CANEZrP1KAVhi_-cxCYe0rR9LUSYJ8MyW8=6eSJZ65FeY5ZJNuQ@mail.gmail.com>
	<20140114225321.GT38964@giles.gnomon.org.uk>
	<CANAnSg0tH_bK_19rsRRHOeZgrGYeWMhW89fXPyS4DQGmS4r_7A@mail.gmail.com>
	<CALimQCXgc0eXeOcqFGUaCpSF7gKEe87KzvLqHZwUysV3WyjjGw@mail.gmail.com>
	<CAAS2fgShChAQryfUOBp60jB-zxn2tH986fu1HfT+LsNdBYnoYg@mail.gmail.com>
	<CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com>
	<20140115230901.GA25135@netbook.cypherspace.org>
	<op.w9q85wkhyldrnw@laptop-air.hsd1.ca.comcast.net>
	<CAAS2fgTRKgkO15VUvVgttP-iEBNF4=G+++Xo-XsaRBmOxyXXKA@mail.gmail.com>
	<op.w90qqfh4yldrnw@laptop-air>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C"
Content-Disposition: inline
In-Reply-To: <op.w90qqfh4yldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy
 (Re: Stealth Addresses)
Precedence: list


--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 '<version> <prefix> <Q1> <Q2> =
=20
> ...', where <prefix> 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 <prefix> verbatim into=
 =20
> the OP_RETURN without knowing how many bits of <prefix> the payee actuall=
y =20
> wants to see there.
>=20
> If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'=
 =20
> where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number=
 =20
> of bits of prefix that should be fixed.
>=20
> Then payer will know how much of <prefix> 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 <prefixLen> 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 <prefix> from =
=20
> the reusable address into OP_RETURN when <prefixLen> is 0, and ending up =
=20
> basically identifying the payee. That's the only reason I can think of to=
 =20
> make '<prefix> <prefixLen>' 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--