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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1W34mJ-0008Lz-3J
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 14:15:39 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.80 as permitted sender)
client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
helo=outmail149080.authsmtp.com;
Received: from outmail149080.authsmtp.com ([62.13.149.80])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W34mD-0001f0-FB for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 14:15:39 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0EEFRfl090662;
Tue, 14 Jan 2014 14:15:27 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 s0EEFIK4095611
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 14 Jan 2014 14:15:20 GMT
Date: Tue, 14 Jan 2014 09:15:17 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140114141517.GA29950@savin>
References: <20140106120338.GA14918@savin>
<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
<20140110102037.GB25749@savin>
<op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
<CANEZrP0Np_FGhw=m6OffijByzz9r4D2AA78jCkzh=NZh=xrbjQ@mail.gmail.com>
<op.w9k6j4xryldrnw@laptop-air.hsd1.ca.comcast.net>
<CANEZrP06EiiY+5hL05bxzdcFXS8V7S1KOiZj86a_ZP5EcoaMKA@mail.gmail.com>
<op.w9mbv6dcyldrnw@laptop-air.hsd1.ca.comcast.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <op.w9mbv6dcyldrnw@laptop-air.hsd1.ca.comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 4d56ae70-7d26-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwYUElQaAgsB AmIbWlBeUVh7W2I7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAWl0 cGdlVhl7cgNHeTBy ZUBlVz5fCEF8JBN6
QlNTQW8AeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4wAjM1 QwwCVRwjEVcIXD4+ NHQA
X-Authentic-SMTP: 61633532353630.1024: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: 1W34mD-0001f0-FB
Cc: "bitcoin-development@lists.sourceforge.net"
<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 14:15:39 -0000
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
> It's a given this will be implemented for Payment Protocol. The question =
=20
> is whether it's also usable outside of PP.
I think what stealth addresses is showing is that the concept of an
address being "instructions on how to generate a txout/tx that results
in me getting Bitcoins" is actually quite valuable; it and
BIP32-derivation addresses with chaincodes are pretty clear cases where
just replacing address with scriptPubKey isn't sufficient.
> I was kind of imagining that we could encourage people to replace all =20
> their static address text that live on Github pages, and README.me, and =
=20
> forum signatures, etc. with new 'href=3Dbitcoin:xSTL...' URIs. Convention=
=20
> could be to require only transporting xSTL addresses within a URI, even =
=20
> going so far as to not support them copy/pasted. 101 characters is not =
=20
> much longer (and sometimes shorter) than PaymentRequest URIs end up being.
Yeah, I don't see anything wrong with stealth addresses whatever length
they wind up being. It's a good intermediate step, and without them
people will just pass around unsigned payment requests and other stuff.
> I think there are ways to make stealth addresses easy enough to use that =
=20
> people actually prefer using them for P2P payments which do not involve a=
=20
> full-stack merchant. In that case, if it was a PaymentRequest it would =
=20
> almost certainly not be signed, and would be more easily shared over emai=
l =20
> or SMS as a URI than as a file attachment or, even worse, putting the =20
> unsigned PR file up on a third-party server which probably won't do a goo=
d =20
> job securing it.
At the DarkWallet hackathon we had discussed how to integrate stealth
addresses into OpenPGP keys as a new user id type for instance, and
similarly into x.509 certs.
The big advantage here is the identity of *who* you are paying is
important, not just "I got this signed payment request". Basically the
concept becomes "identity signed payment address" and the signature
binding the identity to the address is a one time and offline thing; an
issue with the payment protocol as it stands is that it encourages
signing keys to be kept online to issue payment requests. If you have a
scheme where the private keys that bound the identity to the address can
be kept offline you're much better off, because the attacker can only
create a fake payment request, they can't divert the funds to
themselves.
So with that in mind, I strongly suggest sticking with defining a
reasonable stealth address spec. But when you do, keep in mind that you
may want to upgrade it in the future, preferably in a backwards
compatible way. Also, it shouldn't be limited to exactly 2-of-2
CHECKMULTISIG, there's no reason why n and m can't be picked as needed.
Sure, it means the addresses are not fixed length, but for something
that is mostly an internal detail and only occasionally visible to
advanced users, I see no issues there.
Along those lines: what would a BIP32 chain code address look like? What
happens when you want to use that with a multisig-protected wallet?
> * PP Implementation Overview *
>=20
> The basic PaymentRequest>PaymentDetails is expecting 'output' containing =
=20
> one or more TxOuts with script and amount. I believe the general approach=
=20
> is to put a fallback address into 'output' for backward compatibility, an=
d =20
> put Q and Q2 into an extension field.
>=20
> So we add a new optional field to PaymentDetails which contains the one o=
r =20
> two PubKeys. Not sure if we want different protobuf tags, or if the =20
> difference in length of the value makes it obvious enough which approach =
=20
> is being used;
>=20
> optional bytes stealthOnePubKey =3D 1000
> optional bytes stealthTwoPubKey =3D 1001
I think you're missing the bigger picture here, not least of which is
that backwards compatibility is a bit of a misnomer for an unreleased
standard. :)
Why put this into the PaymentDetails? That a stealth address is to be
used for the payment is a property of the outputs being requested, not
the payment itself. We're better off if that goes into the Output
message, and further more it suggests that the Output message shouldn't
contain raw scriptPubKey's but rather addresses. After all, IsStandard()
means we have to inspect the scriptPubKey to see if we can even pay to
what the sender is requesting.
Once you establish that it's addresses that Outputs specify, then it's
easy enough to make a stealth address type, or a BIP32-chain-code
address type, or whatever else comes up in the future.
> Also, ideally I think I would want multiple different stealth payments =
=20
> within a single wallet to the same merchant / pubkeys to be identifiable =
=20
> as such.
Agreed.
--=20
'peter'[:-1]@petertodd.org
00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff
--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJS1UZ1XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwN2RkN2E4N2FlYzMxMWZiN2ZiMTM3NzBmNTRlZGY2MjhlNjk3NmY4YzYw
OTFhNWIyNjM4ODc4YTcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv2ZQf/fJBczwx+ubVOAGSKN08q9wD6
llYExZZ0EbP5FSDPzIIfQnTLPMQWAnkaxlSiRYAEjUyGW7j6FZWLjKjtLAvAB3Oj
oWS0IVVKdyhIesVw5zgb+OX2EUtYuuDF/+aY7p6ENJyJD9QE+ABgqVatdS0f8Y2V
8VQN6sT+DxRNgC3PX668og+i0NJfLzTh7ukTN23xSnJzhITr0oovseDhibe1fFZd
/sOuTlo1R5DupWsNYoLd20MfFCQ0otMEgAa2Dzdw+kg9Ok22huP3NU4c56nQd5+v
CK/NPlvU/ygdHKuLRgdkl3XprYj4REctzAWfDzXHWSYJfCkSH8JaJ7xeCWPWqg==
=ggwL
-----END PGP SIGNATURE-----
--TB36FDmn/VVEgNH/--
|
