1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
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--
|
