diff options
| author | Peter Todd <pete@petertodd.org> | 2014-01-24 04:17:33 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-24 09:17:45 +0000 |
| commit | 161ec0982ea8695207c81f8426e695522c427f6c (patch) | |
| tree | 9dec0dcc3dc071c1e59f346a5bfed277d94d99cc /c2/cf7a3de60d3221bfab243517ea5034b95c5cda | |
| parent | 960bce4afc57ad89a68f9ebff45eac4ea691bdc9 (diff) | |
| download | pi-bitcoindev-161ec0982ea8695207c81f8426e695522c427f6c.tar.gz pi-bitcoindev-161ec0982ea8695207c81f8426e695522c427f6c.zip | |
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
Diffstat (limited to 'c2/cf7a3de60d3221bfab243517ea5034b95c5cda')
| -rw-r--r-- | c2/cf7a3de60d3221bfab243517ea5034b95c5cda | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/c2/cf7a3de60d3221bfab243517ea5034b95c5cda b/c2/cf7a3de60d3221bfab243517ea5034b95c5cda new file mode 100644 index 000000000..ddd031d00 --- /dev/null +++ b/c2/cf7a3de60d3221bfab243517ea5034b95c5cda @@ -0,0 +1,173 @@ +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 <pete@petertodd.org>) 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 <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) +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" + <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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 '<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-- + + |