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
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SFB29-0002u6-7i
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 21:12:57 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SFB28-0002SE-2M
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 21:12:57 +0000
Received: by qcso7 with SMTP id o7so120163qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Apr 2012 14:12:50 -0700 (PDT)
Received: by 10.224.180.200 with SMTP id bv8mr19451351qab.29.1333487570617;
Tue, 03 Apr 2012 14:12:50 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id bm15sm2247466qab.17.2012.04.03.14.12.49
(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 14:12:49 -0700 (PDT)
Message-ID: <4F7B67D6.7090101@gmail.com>
Date: Tue, 03 Apr 2012 17:12:54 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <4F7A1227.7070306@gmail.com> <CABsx9T3MQzJ5gN5xTZ9y5d-og11=mB86cM3ZP4S-fhjs1U+20g@mail.gmail.com> <201204031455.42265.luke@dashjr.org> <CA+s+GJCKcOky=Kfa9cNaEnpO0Lj4Va8a8N=-OZSoXLoO8aUGgQ@mail.gmail.com>
<CAMGNxUujVx0taTh+QR1WFBMKGWcxF-CvCMPwVFWirQ=XyZtquA@mail.gmail.com>
In-Reply-To: <CAMGNxUujVx0taTh+QR1WFBMKGWcxF-CvCMPwVFWirQ=XyZtquA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------050409080903080806040007"
X-Spam-Score: -0.3 (/)
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
(etotheipi[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
1.0 FREEMAIL_REPLY From and body contain different freemails
-0.8 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SFB28-0002SE-2M
Subject: Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
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, 03 Apr 2012 21:12:57 -0000
This is a multi-part message in MIME format.
--------------050409080903080806040007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Just to clarify, I'm not proposing anything to the protocol itself.
Simply that some applications might benefit from users being to sign
messages with existing Bitcoin identities, and what can we do to
accommodate that (out of band)? It's not a high priority, but I think
it's potentially useful, and most codebases already have everything they
need in place to implement it.
On 04/03/2012 04:04 PM, Peter Vessenes wrote:
> I don't think it's minimally invasive to layer PGP's web of trust on
> top of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of
> trust in place was a working concept in the mid-1990s, courtesy of
> David Chaum, I believe.
>
> I totally agree on the kitchen sink concern; I would personally like
> to see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know
> almost nothing about how bitcoin will be used over the next 20 years;
> I believe it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol
> design might be "add simplicity." I'd like to see us adding simplicity
> for now, getting a core set of tests together for alternate
> implementations like libbitcoin, and thinking hard about the dangers
> of cruft over a 10+ year period when it comes to a technology which
> will necessarily include a complete history of every crufty decision
> embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj@gmail.com
> <mailto:laanwj@gmail.com>> wrote:
>
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr.org
> <mailto:luke@dashjr.org>> wrote:
>
> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> > We should avoid reinventing the wheel, if we can. I think we
> should
> > extend existing standards whenever possible.
>
> I wonder if it's possible to make sigs compatible with PGP/EC ?
>
>
> Or we could take a step back, further into "don't reinvent the
> wheel" territory. Why not simply make use of PGP(/EC) to sign and
> verify messages? It has many advantages, like an already existing
> web-of-trust and keyserver infrastructure.
>
> I still feel like this is sign message stuff is dragging the
> kitchen sink into Bitcoin. It's fine for logging into a website,
> what you use it for, but anything that approaches signing email
> (such as S/MIME implementations and handling different character
> encodings) is going too far IMO.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------050409080903080806040007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Just to clarify, I'm not proposing anything to the protocol itself.
Simply that some applications might benefit from users being to sign
messages with existing Bitcoin identities, and what can we do to
accommodate that (out of band)? It's not a high priority, but I
think it's potentially useful, and most codebases already have
everything they need in place to implement it.<br>
<br>
<br>
On 04/03/2012 04:04 PM, Peter Vessenes wrote:
<blockquote
cite="mid:CAMGNxUujVx0taTh+QR1WFBMKGWcxF-CvCMPwVFWirQ=XyZtquA@mail.gmail.com"
type="cite">I don't think it's minimally invasive to layer PGP's
web of trust on top of Bitcoin, in fact, the opposite.
<div><br>
</div>
<div>From a certain angle, bitcoin exists as a sort of answer /
alternate solution to the web of trust. Digital cash with an
existing web of trust in place was a working concept in the
mid-1990s, courtesy of David Chaum, I believe.</div>
<div><br>
</div>
<div>I totally agree on the kitchen sink concern; I would
personally like to see something like a one-year required
discussion period on all non-security changes proposed to the
blockchain protocol. We know almost nothing about how bitcoin
will be used over the next 20 years; I believe it's a mistake to
bulk up the protocol too rapidly right now.</div>
<div><br>
</div>
<div>There's a famous phrase from the founder of Lotus about
Lotus' engineering process: "add lightness." The equivalent for
protocol design might be "add simplicity." I'd like to see us
adding simplicity for now, getting a core set of tests together
for alternate implementations like libbitcoin, and thinking hard
about the dangers of cruft over a 10+ year period when it comes
to a technology which will necessarily include a complete
history of every crufty decision embodied in transaction
histories.</div>
<div><br>
</div>
<div>Peter</div>
<div><br>
<br>
<div class="gmail_quote">On Tue, Apr 3, 2012 at 1:42 PM,
Wladimir <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:laanwj@gmail.com">laanwj@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
<div class="gmail_quote">
<div class="im">On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>On Tuesday, April 03, 2012 2:46:17 PM Gavin
Andresen wrote:<br>
> We should avoid reinventing the wheel, if we
can. I think we should<br>
> extend existing standards whenever possible.<br>
<br>
</div>
I wonder if it's possible to make sigs compatible with
PGP/EC ?<br>
</blockquote>
</div>
<div><br>
Or we could take a step back, further into "don't
reinvent the wheel" territory. Why not simply make use
of PGP(/EC) to sign and verify messages? It has many
advantages, like an already existing web-of-trust and
keyserver infrastructure.<br>
<br>
I still feel like this is sign message stuff is dragging
the kitchen sink into Bitcoin. It's fine for logging
into a website, what you use it for, but anything that
approaches signing email (such as S/MIME implementations
and handling different character encodings) is going too
far IMO. <br>
<span class="HOEnZb"><font color="#888888">
<br>
Wladimir<br>
<br>
</font></span></div>
</div>
<br>
------------------------------------------------------------------------------<br>
Better than sec? Nothing is better than sec when it comes to<br>
monitoring Big Data applications. Try Boundary one-second<br>
resolution app monitoring today. Free.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/Boundary-dev2dev"
target="_blank">http://p.sf.net/sfu/Boundary-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<br>
<div>Peter J. Vessenes</div>
<div>CEO, CoinLab</div>
<div>M: 206.595.9839</div>
<br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/Boundary-dev2dev">http://p.sf.net/sfu/Boundary-dev2dev</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------050409080903080806040007--
|
