Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGjZl-00035E-JI for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 06:27:09 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.54 as permitted sender) client-ip=209.85.219.54; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f54.google.com; Received: from mail-oa0-f54.google.com ([209.85.219.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGjZk-0008UF-CR for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 06:27:09 +0000 Received: by mail-oa0-f54.google.com with SMTP id g12so3212126oah.27 for ; Thu, 20 Feb 2014 22:27:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.84.199 with SMTP id b7mr6587478oez.55.1392964022904; Thu, 20 Feb 2014 22:27:02 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 22:27:02 -0800 (PST) Received: by 10.76.71.231 with HTTP; Thu, 20 Feb 2014 22:27:02 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Feb 2014 06:27:02 +0000 X-Google-Sender-Auth: 2ho_jMVZIGnojH8sTS3lQMplO3Q Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=089e0102dc82c52d1604f2e4b536 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WGjZk-0008UF-CR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 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: Fri, 21 Feb 2014 06:27:09 -0000 --089e0102dc82c52d1604f2e4b536 Content-Type: text/plain; charset=UTF-8 Bear in mind a separate process doesn't buy you anything without a sandbox, and those are expensive (in terms of complexity). On 21 Feb 2014 11:40, "Jeff Garzik" wrote: > [Meta: "Bitcoin Core" is the newfangled branding of bitcoind / > Bitcoin-Qt reference implementation, in case you wondering.] > > Several sites, including BitPay, use bitcoind outside the standard > role of wallet software. bitcoind can be used purely for payment > network access and management. I call this the "border router" role. > Upcoming version 0.9 will feature the ability to disable the bitcoind > wallet at compile time or runtime. This permits a more optimized > border router profile, reducing process size by 40-200MB according to > some reports. > > Recent IRC discussion have floated a rough proposal for a wallet > next-step: Running the Bitcoin Core wallet as a separate process, a > separate binary, from the blockchain engine. The wallet process would > communicate with the blockchain engine using existing RPC and P2P > channels, becoming a real SPV client. This accomplishes a > longstanding security goal of sandboxing away wallet keys and > sensitive data from the network-exposed P2P engine, in a separate > process, among other benefits. > > Simple forking was explored a bit. I did some hacking in that > direction, as it seemed potentially lightweight and somewhat easy to > me: https://github.com/jgarzik/bitcoin/tree/fork fork+pipe is fine > for Linux and OSX/BSD. However, Windows requires an exec-like > solution to create a new process. MSDN does give us a Unix-pipe-like > solution: > http://msdn.microsoft.com/en-us/library/edze9h7e%28v=vs.80%29.aspx > Others pointed to boost interprocess communication APIs, which come > with their own set of caveats. Such a solution would involve a brand > new IPC protocol, and lots of brand new glue code. > > Separate programs seems better. Windows forces us to achieve process > separation via exec-like method. We already have IPC: RPC + P2P. > Modern OS's make localhost sockets just about as fast as other IPCs > methods. Linux, at least, employs zero-copy for localhost sockets in > many situations, similar to the kernel's pipe tricks. > > Pieter has been working on headers-first sync: > https://github.com/bitcoin/bitcoin/pull/2964 Moving along this > wallet/blockchain engine split requires upping the review&test > bandwidth on Pieter's PRs, such as > https://github.com/bitcoin/bitcoin/pull/3514 > > Unsure how much of the separate-binary discussion Gavin saw, so cc'd > for emphasis. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > 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 > --089e0102dc82c52d1604f2e4b536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Bear in mind a separate process doesn't buy you anything= without a sandbox, and those are expensive (in terms of complexity).

On 21 Feb 2014 11:40, "Jeff Garzik" &l= t;jgarzik@bitpay.com> wrote:
[Meta: "Bitcoin Core" is the newfangled branding of bitcoind / Bitcoin-Qt reference implementation, in case you wondering.]

Several sites, including BitPay, use bitcoind outside the standard
role of wallet software. =C2=A0bitcoind can be used purely for payment
network access and management. =C2=A0I call this the "border router&qu= ot; role.
Upcoming version 0.9 will feature the ability to disable the bitcoind
wallet at compile time or runtime. This permits a more optimized
border router profile, reducing process size by 40-200MB according to
some reports.

Recent IRC discussion have floated a rough proposal for a wallet
next-step: =C2=A0Running the Bitcoin Core wallet as a separate process, a separate binary, from the blockchain engine. =C2=A0The wallet process would=
communicate with the blockchain engine using existing RPC and P2P
channels, becoming a real SPV client. =C2=A0This accomplishes a
longstanding security goal of sandboxing away wallet keys and
sensitive data from the network-exposed P2P engine, in a separate
process, among other benefits.

Simple forking was explored a bit. =C2=A0I did some hacking in that
direction, as it seemed potentially lightweight and somewhat easy to
me: https://github.com/jgarzik/bitcoin/tree/fork =C2=A0fork+pipe is fin= e
for Linux and OSX/BSD. =C2=A0However, Windows requires an exec-like
solution to create a new process. =C2=A0MSDN does give us a Unix-pipe-like<= br> solution: http://msdn.microsoft.com/en-us/library= /edze9h7e%28v=3Dvs.80%29.aspx
=C2=A0Others pointed to boost interprocess communication APIs, which come with their own set of caveats. =C2=A0Such a solution would involve a brand<= br> new IPC protocol, and lots of brand new glue code.

Separate programs seems better. =C2=A0Windows forces us to achieve process<= br> separation via exec-like method. =C2=A0We already have IPC: RPC + P2P.
Modern OS's make localhost sockets just about as fast as other IPCs
methods. =C2=A0Linux, at least, employs zero-copy for localhost sockets in<= br> many situations, similar to the kernel's pipe tricks.

Pieter has been working on headers-first sync:
= https://github.com/bitcoin/bitcoin/pull/2964 =C2=A0Moving along this wallet/blockchain engine split requires upping the review&test
bandwidth on Pieter's PRs, such as
= https://github.com/bitcoin/bitcoin/pull/3514

Unsure how much of the separate-binary discussion Gavin saw, so cc'd for emphasis.

--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/

---------------------------------------------------------------------------= ---
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
--089e0102dc82c52d1604f2e4b536--