From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <1393031340.6897.90.camel@staypuft> From: James Hartig Date: Mon, 24 Feb 2014 17:16:12 -0500 Message-ID: To: Wladimir 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. > > > 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
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.

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.

Th= anks,
--
James Hartig
Software Engineer @ Grooveshark.com
http://twitter.com/= jameshartig
=C2=A0
=C2= =A0



On Sat, Feb 22, 2014 at 1:53 AM, Wladimi= r <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<= br> > 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. =C2=A0This would= be
preferred, but in some cases may not be possible. =C2=A0Perhaps it should b= e
optional?

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.

Repeated offenders will lose their BitLicense.
</s>

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!

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.

Wladimir
BTW: All of those patches a= re 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/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e013cba962bd04f04f32e5486--