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
|
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 <jeremy@taplink.co>) id 1W2Pe6-0002SK-Mw
for bitcoin-development@lists.sourceforge.net;
Sun, 12 Jan 2014 18:20:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W2Pe4-0002oG-Pm for bitcoin-development@lists.sourceforge.net;
Sun, 12 Jan 2014 18:20:26 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Sun, 12 Jan 2014 10:28:46 -0800
Content-Type: multipart/alternative; boundary=----------svoj35mbC6KPQXlw6JqQzt
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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>
Date: Sun, 12 Jan 2014 10:20:18 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9k6j4xryldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CANEZrP0Np_FGhw=m6OffijByzz9r4D2AA78jCkzh=NZh=xrbjQ@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -0.7 (/)
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
-0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W2Pe4-0002oG-Pm
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: Sun, 12 Jan 2014 18:20:26 -0000
------------svoj35mbC6KPQXlw6JqQzt
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
> You can always just extend the payment protocol with the new fields as
> well, vs making very long addresses.
I should have mentioned that as Task #4. Agree it could be an optional
extension and backward compatible. I think for displaying the payment in
the UI after it's been made via PP, we have to fully support sending to a
new standard address type anyway. Probably easiest to implement in PP
after the address and transaction building code is done.
So '4a' would be building a static PP file given the necessary inputs.
When I get to that point, I'll send out a draft PP extension with
fields/formats if someone else hasn't already. '4b' would be actually
adding support for parsing those fields and generating the new transaction
type into bitcoind.
Any thoughts on the prefix, and one vs two pubkey approach? First of all,
do we try to support both equally, or favor one over the other? I was
thinking we could have two different 4 byte prefixes but that both render
as xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.
I think the chance of finding a single prefix which looks like xSTL for
both address lengths is 1 in (58^4)^2, so that's probably not going to
happen.
From the payer/user perspective, short stealth vs. long stealth is
irrelevant; they both have the same usability properties from the payer
perspective. So giving them the same Base58 prefix seems like a good plan.
The full 4-byte prefix seems worth the usability trade-off versus 1-byte
prefix, especially since it will impact the ability to lookup the
transaction on an outside service, which I think a lot of people do to
verify their payments. IMO a longer prefix isn't "wasting bytes" anywhere
that it really counts.
We could save two bytes in the address if we required both pubkeys to
start with '03', or save one byte if we required they both start with the
same byte, but again doesn't seem worth it (to me) for the arbitrary
restriction.
The actual internal wallet code for *receiving* STL payments and updating
balances is more tricky and probably not something I can personally tackle
for bitcoind. Assuming we even want first-class support for generating STL
addresses and receiving STL payments in a standard user wallet, someone
has to decide if the STL 'd' / 'd2' keys should be...
1) Encrypted as usual, and then keep a list of blocks with interesting
transactions, and go through them when the user enters their password?
This would cause balances to update differently than how they do now, but
perhaps be more secure.
2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'
unencrypted, with some new concept of 'unconfirmed' until the user enters
their password to prove they can spend that TX? That kind of extra step
seems OK for a merchant but sounds very scary for an average user.
3) Kept encrypted under a separate password? Meh...
And last thought for now... At some point, we might want to decide on a
convention to highlight these STL addresses as 'reusable' -- but similar
questions around revocability remain. I hope we don't need anything like a
UTC expiration time baked in to the address. A static PP file will have an
expiration date either in the certificate or in 'expires' field, so I
think if you want it to expire then use PP?
------------svoj35mbC6KPQXlw6JqQzt
Content-Type: multipart/related; boundary=----------svoj35mbC6KPQX57ksPHtp
------------svoj35mbC6KPQX57ksPHtp
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1389550818119.875f0a785d6b323e@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body><br><blockquote style=3D"margin: 0 0 0.80ex; border-left: #0000FF =
2px solid; padding-left: 1ex"><div dir=3D"ltr">You can always just exten=
d the payment protocol with the new fields as well, vs making very long =
addresses. </div></blockquote><div><br></div><div>I should have men=
tioned that as Task #4. Agree it could be an optional extension and back=
ward compatible. I think for displaying the payment in the UI after it's=
been made via PP, we have to fully support sending to a new standard ad=
dress type anyway. Probably easiest to implement in PP after the address=
and transaction building code is done.</div><div><br></div><div>So '4a'=
would be building a static PP file given the necessary inputs. When I g=
et to that point, I'll send out a draft PP extension with fields/formats=
if someone else hasn't already. '4b' would be actually adding support f=
or parsing those fields and generating the new transaction type into bit=
coind.</div><div><br></div><div>Any thoughts on the prefix, and one vs t=
wo pubkey approach? First of all, do we try to support both equally, or =
favor one over the other? I was thinking we could have two different 4 b=
yte prefixes but that both render as xSTL/tSTL in Base58 but correspond =
to the one vs two pubkeys expected. I think the chance of finding a sing=
le prefix which looks like xSTL for both address lengths is 1 in (58^4)^=
2, so that's probably not going to happen.</div><div><br></div><div>From=
the payer/user perspective, short stealth vs. long stealth is irrelevan=
t; they both have the same usability properties from the payer perspecti=
ve. So giving them the same Base58 prefix seems like a good plan.</div><=
div><br></div><div>The full 4-byte prefix seems worth the usability trad=
e-off versus 1-byte prefix, especially since it will impact the ability =
to lookup the transaction on an outside service, which I think a lot of =
people do to verify their payments. IMO a longer prefix isn't "wasting b=
ytes" anywhere that it really counts.</div><div><br></div><div>We could =
save two bytes in the address if we required both pubkeys to start with =
'03', or save one byte if we required they both start with the same byte=
, but again doesn't seem worth it (to me) for the arbitrary restriction.=
</div><div><br></div><div>The actual internal wallet code for *receiving=
* STL payments and updating balances is more tricky and probably not som=
ething I can personally tackle for bitcoind. Assuming we even want first=
-class support for generating STL addresses and receiving STL payments i=
n a standard user wallet, someone has to decide if the STL 'd' / 'd2' ke=
ys should be...</div><div><br></div><div> 1) Encrypted as usual, a=
nd then keep a list of blocks with interesting transactions, and go thro=
ugh them when the user enters their password? This would cause bal=
ances to update differently than how they do now, but perhaps be more se=
cure.</div><div><br></div><div> 2) Kept unencrypted to allow live =
scanning as usual? Or keep just 'd2' unencrypted, with some new concept =
of 'unconfirmed' until the user enters their password to prove they can =
spend that TX? That kind of extra step seems OK for a merchant but sound=
s very scary for an average user.</div><div><br></div><div> 3) Kep=
t encrypted under a separate password? Meh...</div><div><br></div><div>A=
nd last thought for now... At some point, we might want to decide on a c=
onvention to highlight these STL addresses as 'reusable' -- but similar =
questions around revocability remain. I hope we don't need anything like=
a UTC expiration time baked in to the address. A static PP file will ha=
ve an expiration date either in the certificate or in 'expires' field, s=
o I think if you want it to expire then use PP?</div></body></html>
------------svoj35mbC6KPQX57ksPHtp--
------------svoj35mbC6KPQXlw6JqQzt--
|
