From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGjJC-0004pf-Hj for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 06:10:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.49 as permitted sender) client-ip=74.125.82.49; envelope-from=jgarzik@bitpay.com; helo=mail-wg0-f49.google.com; Received: from mail-wg0-f49.google.com ([74.125.82.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGjJB-0000Ol-DI for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 06:10:02 +0000 Received: by mail-wg0-f49.google.com with SMTP id y10so2174862wgg.4 for ; Thu, 20 Feb 2014 22:09:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=eDgTSdgRkqL2Adz2KI/yaYdkSrGeTxtIKnMXzBvMjAY=; b=UavkguV4hYT5V2T21JIBFzy3GhPOmIRoFI4z1AQEGlBVgV9WxGWYA7tmtDNeo5fhgd 88x4Htq4x4WXvSJN2GKjAHZD8h4tSwAMIX1/76H9IKKs179g4Oic01TuSe2wUgkqRKOv vdGIPosDXLMsPskIZRKvsHdHGa894pSkiSk52MwmSynftF5OcjE+ew2/rNvHlnDLYyrR UNYORNNUJHCtNrzvlP9u08ujPf64cq7oGE9VnLiM5ciTAUfmzz7NlmXQYAnFG4wVUAIg a0P+6XgHUVSFg/rbDOfbkcsmVLvl7VO8H7fXxmU4eNm3ixM9HJ+8//X6CKuNXYKgJz2n AD9Q== X-Gm-Message-State: ALoCoQmcFlcQ3YOnWSpyCSUrJwjsYJ3htSJdYz2A7BHwq7rFBqA2hCmL5Ixyyaz4ruPvxRHBHDwR MIME-Version: 1.0 X-Received: by 10.194.192.233 with SMTP id hj9mr5528492wjc.78.1392962995069; Thu, 20 Feb 2014 22:09:55 -0800 (PST) Received: by 10.194.82.197 with HTTP; Thu, 20 Feb 2014 22:09:55 -0800 (PST) Date: Fri, 21 Feb 2014 01:09:55 -0500 Message-ID: From: Jeff Garzik To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 -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: 1WGjJB-0000Ol-DI Subject: [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:10:02 -0000 [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/