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 <peter@coinlab.com>) id 1SFAvT-0006Md-Vr
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 21:06:03 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.160.175 as permitted sender)
client-ip=209.85.160.175; envelope-from=peter@coinlab.com;
helo=mail-gy0-f175.google.com;
Received: from mail-gy0-f175.google.com ([209.85.160.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SFAvS-0004LP-WF
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 21:06:03 +0000
Received: by ghbz2 with SMTP id z2so126478ghb.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Apr 2012 14:05:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=zdl5fNxnzZGejr09HZ50hDbWjTD3k89YlnAcGXScVfo=;
b=fu6PKawP+llWoEFPXgQZoEZqPRIRcdeSje/9IEC5awuYo8AEPz35Dq2pxx7wVSBV64
jrlfGJndtjbK8l/nP3c/meePhNLLaYggyYWDl0q6xnGIUOtukeJpyRJByOt26U+gmc+Y
U7Dxn75jHb9u8NUmBhTyEdxkukmWWoO2TNnkEVkRsGWXpi5+Mt44CdcpbiQANEn/BbAR
8wMGMaHCHXwzfrWpLSdwbmcXg9lGpr77EH130rMD1rgXMbxWk+kK2Q+g4Fy55giGhjHB
b6EneAqOGL2oZHMyW1z9uVqx0SwEk4g1Pwgpc0M3D/jZJSWWkOsCEJ069REDGOUjih+i
3+HA==
Received: by 10.60.10.137 with SMTP id i9mr21937468oeb.23.1333483479281; Tue,
03 Apr 2012 13:04:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.111.38 with HTTP; Tue, 3 Apr 2012 13:04:19 -0700 (PDT)
In-Reply-To: <CA+s+GJCKcOky=Kfa9cNaEnpO0Lj4Va8a8N=-OZSoXLoO8aUGgQ@mail.gmail.com>
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>
From: Peter Vessenes <peter@coinlab.com>
Date: Tue, 3 Apr 2012 14:04:19 -0600
Message-ID: <CAMGNxUujVx0taTh+QR1WFBMKGWcxF-CvCMPwVFWirQ=XyZtquA@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f81a18b0dc04bccbd146
X-Gm-Message-State: ALoCoQkygUlZoWlXWSesGt7MMGo/A8LcEp3CrhfCjKbtDL2yFyxg5UG7QHDCJLpnNMCLmckWPen4
X-Spam-Score: -0.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
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SFAvS-0004LP-WF
Cc: bitcoin-development@lists.sourceforge.net
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:06:04 -0000
--e89a8fb1f81a18b0dc04bccbd146
Content-Type: text/plain; charset=ISO-8859-1
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> wrote:
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <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
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
--e89a8fb1f81a18b0dc04bccbd146
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I don't think it's minimally invasive to layer PGP's web of tru=
st on top of Bitcoin, in fact, the opposite.=A0<div><br></div><div>From a c=
ertain angle, bitcoin exists as a sort of answer / alternate solution to th=
e web of trust. Digital cash with an existing web of trust in place was a w=
orking 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 pe=
rsonally like to see something like a one-year required discussion period o=
n all non-security changes proposed to the blockchain protocol. We know alm=
ost nothing about how bitcoin will be used over the next 20 years; I believ=
e 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 a=
bout Lotus' engineering process: "add lightness." The equival=
ent for protocol design might be "add simplicity." I'd like t=
o see us adding simplicity for now, getting a core set of tests together fo=
r alternate implementations like libbitcoin, and thinking hard about the da=
ngers of cruft over a 10+ year period when it comes to a technology which w=
ill necessarily include a complete history of every crufty decision embodie=
d in transaction histories.</div>
<div><br></div><div>Peter</div><div><br><br><div class=3D"gmail_quote">On T=
ue, Apr 3, 2012 at 1:42 PM, Wladimir <span dir=3D"ltr"><<a href=3D"mailt=
o:laanwj@gmail.com">laanwj@gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<br><div class=3D"gmail_quote"><div class=3D"im">On Tue, Apr 3, 2012 at 8:5=
5 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" targ=
et=3D"_blank">luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;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 ?<b=
r></blockquote></div><div><br>Or we could take a step back, further into &q=
uot;don't reinvent the wheel" territory. Why not simply make use o=
f PGP(/EC) to sign and verify messages? It has many advantages, like an alr=
eady existing web-of-trust and keyserver infrastructure.<br>
<br>I still feel like this is sign message stuff is dragging the kitchen si=
nk 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 implementat=
ions and handling different character encodings) is going too far IMO. <br>
<span class=3D"HOEnZb"><font color=3D"#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 href=3D"http://p.sf.net/sfu/Boundary-dev2dev" target=3D"_blank">http://p=
.sf.net/sfu/Boundary-dev2dev</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>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><br><div=
>Peter J. Vessenes</div><div>CEO, CoinLab</div><div>M: 206.595.9839</div><b=
r>
</div>
--e89a8fb1f81a18b0dc04bccbd146--
|
