summaryrefslogtreecommitdiff
path: root/ca/c7d035ee42e4c5ed50f3ddde36476d877e61d4
blob: cfd4a53eb73cf1425c5f2c4f803cfc084f7224a3 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1V1HnJ-0000wp-45
	for bitcoin-development@lists.sourceforge.net;
	Mon, 22 Jul 2013 15:13:01 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.175 as permitted sender)
	client-ip=209.85.217.175; envelope-from=melvincarvalho@gmail.com;
	helo=mail-lb0-f175.google.com; 
Received: from mail-lb0-f175.google.com ([209.85.217.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V1HnF-0001ZE-Nz
	for bitcoin-development@lists.sourceforge.net;
	Mon, 22 Jul 2013 15:13:01 +0000
Received: by mail-lb0-f175.google.com with SMTP id r10so5364401lbi.20
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 22 Jul 2013 08:12:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.4.65 with SMTP id i1mr12822879lai.21.1374505970816; Mon,
	22 Jul 2013 08:12:50 -0700 (PDT)
Received: by 10.112.59.193 with HTTP; Mon, 22 Jul 2013 08:12:50 -0700 (PDT)
In-Reply-To: <20130722144458.GA22993@vps7135.xlshosting.net>
References: <20130722144458.GA22993@vps7135.xlshosting.net>
Date: Mon, 22 Jul 2013 17:12:50 +0200
Message-ID: <CAKaEYhKxLup6yJEYeC+VL6KMzGZ3DhQzJ0Rs9RJc3CU-UhNKag@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e0149338021dc4004e21b1c8f
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1V1HnF-0001ZE-Nz
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Standard for private keys with
	birth timestamp
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: Mon, 22 Jul 2013 15:13:01 -0000

--089e0149338021dc4004e21b1c8f
Content-Type: text/plain; charset=ISO-8859-1

On 22 July 2013 16:44, Pieter Wuille <pieter.wuille@gmail.com> wrote:

> Hello,
>
> I should have brought up this suggestion before, as there seems to be
> relevant other work.
>
> I'd like to propose encoding keys data (whatever type) with a birth
> timestamp as:
>  * <serialized key>@<unix timestamp in decimal>
>
> The reason for not incorporating this inside the key serialization (for
> example BIP32), is because
> birth timestamps are more generally a property of an address, rather than
> the key it is derived from.
> For one, it is useful for non-extended standard serialized private keys,
> but for P2SH addresses,
> the "private key" is really the actual scriptPubKey, but birth data is
> equally useful for this.
>
> Reason for choosing the '@' character: it's not present in the base58,
> hex, or base64 encodings that
> are typically used for key/script data.
>
> One downside is that this means no checksum-protection for the timestamp,
> but the advantage is
> increased genericity. It's also longer than using a binary encoding, but
> this is an optional
> part anyway, and I think "human typing" is already fairly hard anyway.
>

Is there a BIP for this?

@ is normally used in conjunction with things other than a time stamp ...

You may want to look at RFC 4151

http://www.ietf.org/rfc/rfc4151.txt

They had an idea on adding time stamps to identifiers.

First impression is that the sacrifice in opacity does not seem to justify
the utility.


>
> --
> Pieter
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e0149338021dc4004e21b1c8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 22 July 2013 16:44, Pieter Wuille <span dir=3D"ltr">&lt;<a href=
=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I should have brought up this suggestion before, as there seems to be relev=
ant other work.<br>
<br>
I&#39;d like to propose encoding keys data (whatever type) with a birth tim=
estamp as:<br>
=A0* &lt;serialized key&gt;@&lt;unix timestamp in decimal&gt;<br>
<br>
The reason for not incorporating this inside the key serialization (for exa=
mple BIP32), is because<br>
birth timestamps are more generally a property of an address, rather than t=
he key it is derived from.<br>
For one, it is useful for non-extended standard serialized private keys, bu=
t for P2SH addresses,<br>
the &quot;private key&quot; is really the actual scriptPubKey, but birth da=
ta is equally useful for this.<br>
<br>
Reason for choosing the &#39;@&#39; character: it&#39;s not present in the =
base58, hex, or base64 encodings that<br>
are typically used for key/script data.<br>
<br>
One downside is that this means no checksum-protection for the timestamp, b=
ut the advantage is<br>
increased genericity. It&#39;s also longer than using a binary encoding, bu=
t this is an optional<br>
part anyway, and I think &quot;human typing&quot; is already fairly hard an=
yway.<br></blockquote><div><br></div><div>Is there a BIP for this?<br><br><=
/div><div>@ is normally used in conjunction with things other than a time s=
tamp ...<br>
</div><div><br>You may want to look at RFC 4151<br><br><a href=3D"http://ww=
w.ietf.org/rfc/rfc4151.txt">http://www.ietf.org/rfc/rfc4151.txt</a><br><br>=
</div><div>They had an idea on adding time stamps to identifiers.=A0 <br><b=
r>
</div><div>First impression is that the sacrifice in opacity does not seem =
to justify the utility.<br></div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">

<br>
--<br>
Pieter<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
See everything from the browser to the database with AppDynamics<br>
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>
Start your free trial of AppDynamics Pro today!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--089e0149338021dc4004e21b1c8f--