From: Peter Todd <pete@petertodd•org>
To: Jeremy Spilman <jeremy@taplink•co>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
Date: Fri, 24 Jan 2014 04:17:33 -0500 [thread overview]
Message-ID: <20140124091733.GC15398@savin> (raw)
In-Reply-To: <op.w90qqfh4yldrnw@laptop-air>
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
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>
> ...', where <prefix> is 2 bytes. Without any length indicator. What's the
> payer going to put on the blockchain? How would they know what the 'rest
> of the space' is? They would have to put the whole <prefix> verbatim into
> the OP_RETURN without knowing how many bits of <prefix> the payee actually
> wants to see there.
>
> If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'
> where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number
> of bits of prefix that should be fixed.
>
> Then payer will know how much of <prefix> from the address should be taken
> verbatim, and the rest of the two bytes would be replaced with random
> data, and exactly two bytes would be put in the OP_RETURN.
>
> If <prefixLen> was zero, the 2 byte prefix in the reusable address must be
> ignored, and an entirely random 2 byte prefix would be put into the
> OP_RETURN.
>
> I'm a bit worried about broken implementations copying the <prefix> from
> the reusable address into OP_RETURN when <prefixLen> is 0, and ending up
> basically identifying the payee. That's the only reason I can think of to
> make '<prefix> <prefixLen>' optional in the reusable address, to prevent
> the opportunity to screw it up. You would *still* put a 2-byte random
> prefix in the OP_RETURN, even if the fields weren't in the address at all.
> 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.
--
'peter'[:-1]@petertodd.org
00000000000000003590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-01-24 9:17 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 12:03 [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-08 10:20 ` Jeremy Spilman
2014-01-10 10:20 ` Peter Todd
2014-01-10 11:28 ` Drak
2014-01-10 12:00 ` Peter Todd
2014-01-12 10:33 ` Jeremy Spilman
2014-01-12 12:51 ` Mike Hearn
2014-01-12 18:20 ` Jeremy Spilman
2014-01-12 18:26 ` Mike Hearn
2014-01-13 9:13 ` Jeremy Spilman
2014-01-14 14:15 ` Peter Todd
2014-01-14 17:54 ` Odinn Cyberguerrilla
2014-01-12 21:18 ` Gavin Andresen
2014-01-13 9:52 ` Gregory Maxwell
2014-01-13 10:39 ` Mike Hearn
2014-01-13 13:37 ` Roy Badami
2014-01-13 15:58 ` Mike Hearn
2014-01-13 20:11 ` Roy Badami
2014-01-14 22:53 ` Roy Badami
2014-01-15 0:19 ` Drak
2014-01-15 20:22 ` Ben Davenport
2014-01-15 20:38 ` Gregory Maxwell
2014-01-15 20:44 ` Jeff Garzik
2014-01-15 22:38 ` [Bitcoin-development] Static addresses on chains encouraging address *RE* use Troy Benjegerdes
2014-01-15 23:01 ` [Bitcoin-development] Stealth Addresses Mike Hearn
2014-01-15 23:04 ` Roy Badami
2014-01-15 23:07 ` Jeff Garzik
2014-01-15 23:17 ` Roy Badami
2014-01-15 23:19 ` Roy Badami
2014-01-15 23:09 ` [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses) Adam Back
2014-01-16 1:02 ` Jeremy Spilman
2014-01-16 1:32 ` Gregory Maxwell
2014-01-18 17:44 ` Troy Benjegerdes
2014-01-18 20:25 ` Christophe Biocca
2014-01-20 11:11 ` Peter Todd
2014-01-21 4:00 ` Jeremy Spilman
2014-01-24 9:17 ` Peter Todd [this message]
2014-01-16 11:42 ` Adam Back
2014-01-16 18:19 ` Troy Benjegerdes
2014-01-16 0:05 ` [Bitcoin-development] Stealth Addresses Jeremy Spilman
2014-01-16 0:10 ` Gregory Maxwell
2014-01-16 0:24 ` Mark Friedenbach
2014-01-16 0:44 ` Eric Martindale
2014-01-16 6:26 ` Gary Rowe
2014-01-16 9:48 ` Wladimir
2014-01-16 1:16 ` Odinn Cyberguerrilla
2014-01-16 10:14 ` Drak
2014-01-16 10:19 ` Mike Hearn
2014-01-16 11:12 ` [Bitcoin-development] reusable address privacy problems & fuzzy bait limitations (Re: Stealth Addresses) Adam Back
2014-01-16 21:28 ` [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-17 2:30 ` Johnathan Corgan
2014-01-17 3:13 ` Jeremy Spilman
2014-01-17 7:49 ` Drak
2014-01-17 9:15 ` Mike Hearn
2014-01-17 9:19 ` Mark Friedenbach
2014-01-17 9:23 ` Natanael
2014-01-17 9:59 ` Drak
2014-01-17 20:16 ` Cameron Garnham
2014-01-17 14:46 ` Peter Todd
2014-01-17 19:21 ` Ben Davenport
2014-01-18 4:55 ` Alan Reiner
2014-01-18 5:09 ` Gregory Maxwell
2014-01-18 23:12 ` Jeremy Spilman
2014-01-18 23:50 ` Gregory Maxwell
2014-01-20 11:08 ` Peter Todd
2014-01-13 19:53 ` Roy Badami
2014-01-13 19:57 ` Mike Hearn
2014-01-13 20:01 ` Roy Badami
2014-01-13 19:40 ` Roy Badami
2014-01-13 19:44 ` Drak
2014-01-13 19:59 ` Alan Reiner
2014-01-13 20:10 ` Gregory Maxwell
2014-01-13 20:15 ` Peter Todd
2014-01-13 22:02 ` Jeremy Spilman
2014-01-14 14:19 ` Peter Todd
2014-01-14 19:12 ` Jeremy Spilman
2014-01-14 20:48 ` Peter Todd
2014-01-14 21:51 ` Adam Back
2014-01-14 22:34 ` Jeremy Spilman
2014-01-13 20:14 ` Peter Todd
2014-01-13 20:41 ` Alan Reiner
2014-01-13 20:47 ` Gregory Maxwell
2014-01-13 21:02 ` Roy Badami
2014-01-13 21:15 ` Alan Reiner
2014-01-13 21:27 ` Peter Todd
[not found] ` <op.w9ne31oqyldrnw@laptop-air.hsd1.ca.comcast.net>
2014-01-14 12:10 ` Peter Todd
2014-03-06 12:23 ` Dan Carter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140124091733.GC15398@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox