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 ser
On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell <
dtramm...@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
> > restr
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. T
On Fri, Feb 21, 2014 at 7:50 AM, William Yager wrote:
> Running the network part of the core as a system service might make sense
> for server implementations, but it’s a pain in the rear for most users.
>
Come on, making it a possibility doesn't affect other kinds of use cases in
any way. Are y
Running the network part of the core as a system service might make sense for
server implementations, but it’s a pain in the rear for most users.
That said, I think segregating the two processes is a great idea. Let’s just
try to avoid some complicated scheme that involves necessarily running t
On Fri, Feb 21, 2014 at 7:27 AM, Mike Hearn wrote:
> Bear in mind a separate process doesn't buy you anything without a
> sandbox, and those are expensive (in terms of complexity).
>
Sandboxing in user space is complex, agreed,
The most straightforward way would be to run the blockchain daemon a
6 matches
Mail list logo
