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 1WzMkw-0003Jj-RG for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 09:11:10 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.175 as permitted sender) client-ip=209.85.223.175; envelope-from=mh.in.england@gmail.com; helo=mail-ie0-f175.google.com; Received: from mail-ie0-f175.google.com ([209.85.223.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzMkv-0007cn-4x for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 09:11:10 +0000 Received: by mail-ie0-f175.google.com with SMTP id tp5so7360211ieb.34 for ; Tue, 24 Jun 2014 02:11:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.142.169 with SMTP id rx9mr25245532oeb.1.1403601063326; Tue, 24 Jun 2014 02:11:03 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Tue, 24 Jun 2014 02:11:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Jun 2014 11:11:03 +0200 X-Google-Sender-Auth: -a2S50HCzBWk6i44holWn7Hw8gM Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=047d7b1634edc93bca04fc91562f 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: 1WzMkv-0007cn-4x Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Plans to separate wallet from core 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: Tue, 24 Jun 2014 09:11:11 -0000 --047d7b1634edc93bca04fc91562f Content-Type: text/plain; charset=UTF-8 > > So first bitcoind will support SPV mode then we separate the wallet? > Are the core and the wallet share any code (say, the p2p messages via > a sub-repo or something)? > bitcoind already supports SPV mode, that's how bitcoinj clients work. However the current wallet code doesn't use it, it integrates directly with the full mode main loop and doesn't talk P2P internally. Which is the fine and obvious way to implement the wallet feature. I'm not totally convinced it should become an SPV wallet given the complexity of doing that. But if you did want to separate the wallet code from the full node then that'd be the way to do it. The question is; what does this buy us, and is it worth the potentially huge amount of time it could take? My gut feeling is we have bigger fish to fry. There's plenty of work to do just on the core consensus code, making Bitcoin Core into a competitive wallet as well would be an additional burden. However I may be quite biased, as I am the maintainer of what is primarily a wallet library :) > I'm sorry, but I still don't know what Electrum has to do with all this. > People use Electrum as shorthand to mean "something a bit like the P2P network, but with trusted remote servers which build additional databases and thus support additional commands". --047d7b1634edc93bca04fc91562f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So first bitcoind will support SPV mode then we = separate the wallet?
Are the core and the wallet share any code (say, the p2p messages via
a sub-repo or something)?

bitcoind alre= ady supports SPV mode, that's how bitcoinj clients work. However the cu= rrent wallet code doesn't use it, it integrates directly with the full = mode main loop and doesn't talk P2P internally. Which is the fine and o= bvious way to implement the wallet feature. I'm not totally convinced i= t should become an SPV wallet given the complexity of doing that. But if yo= u did want to separate the wallet code from the full node then that'd b= e the way to do it.

The question is; what does this buy us, and is it worth= the potentially huge amount of time it could take? My gut feeling is we ha= ve bigger fish to fry. There's plenty of work to do just on the core co= nsensus code, making Bitcoin Core into a competitive wallet as well would b= e an additional burden.

However I may be quite biased, as I am the maintainer o= f what is primarily a wallet library :)
=C2=A0
I'm sorry, but I still don't know what Electrum has= to do with all this.

People use = Electrum as shorthand to mean "something a bit like the P2P network, b= ut with trusted remote servers which build additional databases and thus su= pport additional commands".
--047d7b1634edc93bca04fc91562f--