From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WzMhH-0007sD-95 for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 09:07:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.176 as permitted sender) client-ip=209.85.223.176; envelope-from=laanwj@gmail.com; helo=mail-ie0-f176.google.com; Received: from mail-ie0-f176.google.com ([209.85.223.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzMhG-0000tM-Aa for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 09:07:23 +0000 Received: by mail-ie0-f176.google.com with SMTP id rd18so7248443iec.21 for ; Tue, 24 Jun 2014 02:07:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.4.102 with SMTP id j6mr550823igj.42.1403600836300; Tue, 24 Jun 2014 02:07:16 -0700 (PDT) Received: by 10.64.60.195 with HTTP; Tue, 24 Jun 2014 02:07:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Jun 2014 11:07:16 +0200 Message-ID: From: Wladimir To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (laanwj[at]gmail.com) -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: 1WzMhG-0000tM-Aa 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:07:23 -0000 On Mon, Jun 23, 2014 at 10:15 PM, Jorge Tim=C3=B3n wro= te: > On 6/23/14, Wladimir wrote: >> It's least surprising if the wallet works as a SPV client by default. >> Then, users can use it without first setting up a core. Thus the idea >> would be to use P2P primarily. > > 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)? Yes, they will share code. At least the basic data structures and serialization and deserialization. Probably also part of the network code and utilities like argument parsing (although that's not a hard requirement - it may be an opportunity to do things better). So part of Bitcoin Core will have to be turned into a library or libraries. Movement toward this is already in progress for a while. >> There could be a mode to use a trusted core by RPC for >> mempool/conflicted transaction validation and such. But I'm not sure >> about this - as we've seen, pure-SPV wallets work pretty well. If you >> want it to act as an edge router you can point a SPV wallet at your >> trusted core as well. > > I thought we would first separate wallet from core (maintaining the > full-node wallet status) and then implement an optional SPV mode for > the core (and transitively for "qt-wallet", which would support both > full and SPV mode). We want to move away from "full node wallets". In the beginning it made some sense to jump-start the network, but the more the chain grows the less unwieldy they become. My main argument for the split is that full nodes and wallets have completely different usage scenarios: - A wallet should be online as little as possible, ideally only when you do transactions or want to check for them. - A full node should be online 24/7 or it is virtually useless to the netwo= rk. >> There are no plans for adding Electrum-like functionality to bitcoind. >> There is already Electrum. Let's not reinvent any wheels. > > I'm sorry, but I still don't know what Electrum has to do with all this. I suggest you look at the interface for Electrum. It probably does exactly what you expected the interface between the Bitcoin Core wallet and Bitcoin Core to become. Electrum server keeps some extra indices that can be queried by the wallets. It already exists! But IMO this is a passed stage. SPV wallets w/ Bloom filtering can work without any special servers, so why require a 'close binding' to a trusted bitcoin core? (As said - I'm fine with optional close binding to a core using RPC with slight security benefits like utxo queries and conflicted transaction checking, and to get the dynamic fee data, but it should not be required) >> It does not need to keep a full chain database. But it needs its own >> record of the chain, headers-only + what concerns the keys in the >> wallet. > > Why cannot consume that data from a bitcoind node that always run alongsi= de it? To not require having a bitcoind node always running alongside it. Wladimir