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
174
175
176
177
178
179
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W32pl-0003kC-NZ
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 12:11:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W32pj-0002bL-Fk for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 12:11:05 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0ECAvTe031197;
Tue, 14 Jan 2014 12:10:57 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 s0ECApS7046531
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 14 Jan 2014 12:10:54 GMT
Date: Tue, 14 Jan 2014 07:10:51 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140114121051.GA2583@savin>
References: <CAAS2fgTz0TaGhym_35V3N2-vHVzU9BeuV8q+QJjwh5bg77FEZg@mail.gmail.com>
<20140113194049.GJ38964@giles.gnomon.org.uk>
<CANAnSg30V01B_3LCJ09sTwcsYa4_WOg3sKd-=p6COZS6w0b-uA@mail.gmail.com>
<52D4458C.6010909@gmail.com> <20140113201407.GB7941@petertodd.org>
<52D44F86.1040407@gmail.com>
<20140113210217.GO38964@giles.gnomon.org.uk>
<52D45755.60402@gmail.com> <20140113212752.GA9098@petertodd.org>
<op.w9ne31oqyldrnw@laptop-air.hsd1.ca.comcast.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
In-Reply-To: <op.w9ne31oqyldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: eb13fb14-7d14-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwYUElQaAgsB AmIbWlZeUV17XGc7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAWly d159VRl2cQBFeTBx Y09mWT4ODkV5IxR8
RlNTQWwCeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4wAjM1 QwwCVRwjEVcIXD4+ NHQA
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: 1W32pj-0002bL-Fk
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 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: Tue, 14 Jan 2014 12:11:06 -0000
--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd <pete@petertodd.org> wrote:
>=20
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that
> >grinding can be done with hash operations rather than ECC - even if we
> >needed 32-bit prefixes eventually computing 32-bit hash collisions is
> >plausible, and more reasonable 8-bit is quite doable now.
>=20
> I'll be updating my test code to support a prefix on the OP_RETURN
> TxOut, for either where we expect to have an index on scriptPubKey,
> or where we have an index on H(scriptPubKey) and have to grind with
> a nonce.
>=20
> Where do we say what prefix we are targeting, or how many bits
> should match with Q? I assume the only place to communicate this,
> dare I say it, is in the address string.
That's exactly where you need to put it.
Incidentally a prefix nonce, either direct or grind-style, is a bit of a
privacy leak by suggestion how long the prefix was in the original
stealth address. Code should be written such that grinding routines
start at a random nonce, and nonces of any length are accepted. The
easiest way to do that is to just stick the grind nonce at the end after
the 33 bytes of pubkey.
I dunno yet what hashing algorithm to target for grinding. I'd assume
SHA256^2 on the basis that it's identical to what the merkle tree uses
and thus will have the same security properties in a committed index,
but I can see people pushing for the shorter 20-byte HASH160 too.
> Also, for symmetric encryption of P in the OP_RETURN TxOut using a
> key H(Q), what cipher did you have in mind? Since P is ephemeral and
> random, I don't follow, why does encrypting it 'gives a slightly
> larger anonymity set'?
The idea was to make the anonymity set include other uses of OP_RETURN
txouts, however Gregory Maxwell pointed out that it'd easily lead to a
much reduced anonymity set because someone could trial decrypt the
encrypted P and check if it was a valid pubkey. If you encrypted the
full 33 bytes that'd be a total disaster - only 1/256 candidate stealth
keys would work. There are ways to do it right, but it's tricky and
there may be other attacks I don't know about, so I'm inclined to just
drop that idea for now unless a professional cryptographer wants to take
it on.
> You made an interesting point in the original post that payer should
> hold onto their ephemeral privKey 'e' corresponding to pubKey P if
> they need to later prove the payment was actually sent to Q.
Yup. You can even use that pubkey to disambiguate/prove payments with
Timo Hanke's pay-to-contract ideas by deriving it from some root and a
contract hash.
Conversely Amir Taaki pointed out on the unsystem list that once a nonce
is agreed on, it can be used directly with BIP32 derivation so that
future payments don't have to use an OP_RETURN txout. Interesting idea,
although I worry that the statelessness advantage of stealth payments
gets lost if you do that. Probably best to look at that one after an
initial implementation happens and we get some experience with them in
the real world - adding that can be done in a backwards compatible
fashion.
> Finally, I hope you can take a look at the Gist and sample Test-Net
> TXs I sent out this morning. I just went back and re-read your
> original post, and compared to what I implemented there are some
> differences, I'd like to make sure you think it's on track.
Will do.
--=20
'peter'[:-1]@petertodd.org
0000000000000001420349f2276e53e5b087faea67c7c40aa12383c416067364
--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJS1SlKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwNzRiOTI1YmY4M2EwM2QwNGNjYzk3N2RhY2Y2YTFjNDViYzVlNDljZWUz
YzhmNWM1MjczMzBkZDAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftWWAf+NhqSxxLzEiYHEPZHaH4anmhO
H9hgHWqD6LKunlDLjfLZjy4xiX+kkqgnR6ANTwS0bNMg9uGt/q5IGSDm1lv0WX/S
6/kZfJdSVgdDykKbyVnHkduH69i91H5xf9WL3zX+aEi1sRdPBJwWN8P4v7EeJhRB
UzrpOu2jhhCi6u7NWqsI64ddh0MMEvLuJVmEgA0hARSQNnQ7dElB1Npwog59pu4p
0g8mPYA1wDezKya1nfI4HdXKIG/X9JB82phL7gT/XHVPXW1eteVW4eZjum6Hh4Uo
Nh2nW2IcUQA3IY0Gxdr35VaAxNPcev7sa5cHUS2ufg6YN4vPDw0IHdEQYxWhkw==
=41AH
-----END PGP SIGNATURE-----
--5mCyUwZo2JvN/JJP--
|
