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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <fastest963@gmail.com>) id 1WI3pc-0001Q7-6H
for bitcoin-development@lists.sourceforge.net;
Mon, 24 Feb 2014 22:17:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.171 as permitted sender)
client-ip=209.85.216.171; envelope-from=fastest963@gmail.com;
helo=mail-qc0-f171.google.com;
Received: from mail-qc0-f171.google.com ([209.85.216.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WI3pa-0006N8-FQ
for bitcoin-development@lists.sourceforge.net;
Mon, 24 Feb 2014 22:17:00 +0000
Received: by mail-qc0-f171.google.com with SMTP id x13so2126657qcv.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 24 Feb 2014 14:16:53 -0800 (PST)
X-Received: by 10.224.11.196 with SMTP id u4mr33995553qau.4.1393280213043;
Mon, 24 Feb 2014 14:16:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.47.134 with HTTP; Mon, 24 Feb 2014 14:16:12 -0800 (PST)
In-Reply-To: <CA+s+GJD=-Y5e7jfBt8Ced-2wXkjYcODBKrre2jqT-k-tQO8fCQ@mail.gmail.com>
References: <CAJHLa0OD7w0Rs5ygAE4C14EWm1=x57YHG2kOee1pzxvj3FQ38g@mail.gmail.com>
<CANEZrP2siw9hGPVsPjQ6WyohacOrs8rqs5p9ZsFY5kF0URnPWg@mail.gmail.com>
<CA+s+GJCRqqmoHkmsq+6x9Wm6btKzdXoPjw5Af8zRDEkDE+6+zw@mail.gmail.com>
<CA+s+GJAgs7otQB_tQNCntZ5gR+gp3+PfA+iiKPsjLu2oenaSUA@mail.gmail.com>
<1393031340.6897.90.camel@staypuft>
<CA+s+GJD=-Y5e7jfBt8Ced-2wXkjYcODBKrre2jqT-k-tQO8fCQ@mail.gmail.com>
From: James Hartig <fastest963@gmail.com>
Date: Mon, 24 Feb 2014 17:16:12 -0500
Message-ID: <CAM6j61sSKqeZFOjovV+oUhg6G+r+eusLHhK9chY07m_Wqxd_Cw@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=089e013cba962bd04f04f32e5486
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
(fastest963[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (fastest963[at]gmail.com)
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: 1WI3pa-0006N8-FQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Bitcoin Core trial balloon:
splitting blockchain engine and wallet
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, 24 Feb 2014 22:17:00 -0000
--089e013cba962bd04f04f32e5486
Content-Type: text/plain; charset=UTF-8
Setting aside all security benefits (which the user can obviously choose to
implement or ignore), a major benefit here is being able to have multiple
wallets use the same blockchain process. I have 3 different bitcoind
processes running on the same server to utilize multiple wallets. Using
them serially isn't an option in my case. Also, peers can run the cheaper
process instead of having the wallet functionality which isn't even used.
On the security front, this doesn't seem to be any less secure and it gives
the user the flexibility to make it as secure as they feel comfortable. If
they want to run them both as the same user with no SELinux or file
protections (this isn't stopping or encouraging that) they're already doing
that now with bitcoind, albeit with possibly a larger attack surface.
Thanks,
--
James Hartig
Software Engineer @ Grooveshark.com
http://twitter.com/jameshartig
On Sat, Feb 22, 2014 at 1:53 AM, Wladimir <laanwj@gmail.com> wrote:
>
> On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell <
> dtrammell@dustintrammell.com> wrote:
>
>> On Fri, 2014-02-21 at 07:43 +0100, Wladimir wrote:
>> > The most straightforward way would be to run the blockchain daemon as
>> > a system service (with its own uid/gid and set of Apparmor/SELinux
>> > restrictions) and the wallet daemon as the user.
>>
>> This assumes you as a user have the rights to do so. This would be
>> preferred, but in some cases may not be possible. Perhaps it should be
>> optional?
>>
>
> No! I'm proposing that we force everyone to do it. Using all means
> necessary. There should be regular audits that everyone is running the
> software exactly in my configuration, and if not, a special task force will
> take care that spankings are carried out on the spot.
>
> Repeated offenders will lose their BitLicense.
> </s>
>
> Please stop kicking this dead horse. It was just a random idea. Maybe a
> way how Linux distributions could structure it, but it may or may not apply
> in your case. And that's fine, this is free software development, you can
> do whatever you want!
>
> Let's try to bring this discussion back to its original intention: for
> anyone that wants to concretely help this along, please help reviewing and
> testing the pull requests that jgarzik mentions.
>
> Wladimir
> BTW: All of those patches are helpful for monolithic-bitcoind as well as
> they (lay the groundwork for) speeding up block synchronization.
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e013cba962bd04f04f32e5486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Setting aside all security benefits (which the user can ob=
viously choose to implement or ignore), a major benefit here is being able =
to have multiple wallets use the same blockchain process. I have 3 differen=
t bitcoind processes running on the same server to utilize multiple wallets=
. Using them serially isn't an option in my case. Also, peers can run t=
he cheaper process instead of having the wallet functionality which isn'=
;t even used.<div>
<br></div><div>On the security front, this doesn't seem to be any less =
secure and it gives the user the flexibility to make it as secure as they f=
eel comfortable. If they want to run them both as the same user with no SEL=
inux or file protections (this isn't stopping or encouraging that) they=
're already doing that now with bitcoind, albeit with possibly a larger=
attack surface.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr">Th=
anks,<br>--<br>James Hartig<br>Software Engineer @ Grooveshark.com<br><a hr=
ef=3D"http://twitter.com/jameshartig" target=3D"_blank">http://twitter.com/=
jameshartig</a><div style=3D"width:16px;height:16px;display:inline-block">
=C2=A0</div><div style=3D"width:16px;height:16px;display:inline-block">=C2=
=A0</div><br></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Feb 22, 2014 at 1:53 AM, Wladimi=
r <span dir=3D"ltr"><<a href=3D"mailto:laanwj@gmail.com" target=3D"_blan=
k">laanwj@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<div class=3D"">On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell <span d=
ir=3D"ltr"><<a href=3D"mailto:dtrammell@dustintrammell.com" target=3D"_b=
lank">dtrammell@dustintrammell.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On Fri, 2014-02-21 at 07:43 +0100, Wladimir wrote:<br=
>
> The most straightforward way would be to run the blockchain daemon as<=
br>
> a system service (with its own uid/gid and set of Apparmor/SELinux<br>
> restrictions) and the wallet daemon as the user.<br>
<br>
</div>This assumes you as a user have the rights to do so. =C2=A0This would=
be<br>
preferred, but in some cases may not be possible. =C2=A0Perhaps it should b=
e<br>
optional?<br></blockquote><div><br></div></div><div>No! I'm proposing t=
hat we force everyone to do it. Using all means necessary. There should be =
regular audits that everyone is running the software exactly in my configur=
ation, and if not, a special task force will take care that spankings are c=
arried out on the spot.</div>
<div><br></div><div>Repeated offenders will lose their BitLicense.</div><di=
v></s><br></div><div><br></div><div>Please stop kicking this dead hor=
se. It was just a random idea. Maybe a way how Linux distributions could st=
ructure it, but it may or may not apply in your case. And that's fine, =
this is free software development, you can do whatever you want!</div>
<div><br></div><div>Let's try to bring this discussion back to its orig=
inal intention: for anyone that wants to concretely help this along, please=
help reviewing and testing the pull requests that jgarzik mentions.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br></div><div>Wladimir<br></div><div><div>BTW: All of those patches a=
re helpful for monolithic-bitcoind as well as they (lay the groundwork for)=
speeding up block synchronization.</div></div><div><br></div></font></span=
></div>
</div>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&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>
<br></blockquote></div><br></div>
--089e013cba962bd04f04f32e5486--
|
