Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C590E267 for ; Tue, 11 Aug 2015 09:02:14 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C056BB0 for ; Tue, 11 Aug 2015 09:02:13 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 7F4CD2E603C5; Tue, 11 Aug 2015 11:02:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id D14482D00808 for ; Tue, 11 Aug 2015 11:02:11 +0200 (CEST) Message-ID: <55C9BA0F.60408@jonasschnelli.ch> Date: Tue, 11 Aug 2015 11:02:07 +0200 From: Jonas Schnelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: [bitcoin-dev] Future Of Bitcoin-Cores Wallet X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:02:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi (excuse my english; it’s not my native language) As you might noticed, bitcoin-cores wallet didn’t got that much focus during the last month (even years?). Wallet development has mostly moved towards SPV (bitcoinj), thin clients (Electrum), centralized web middleware (Copay, Greenaddress, etc.). Obviously this direction was highly appreciated by users who now can now run a bitcoin-client (SPV / thin client) on a smartphone or on a computer with tiny available resources. Full validation slowly gets a privilege of people who can manage to run bitcoin-core on a VPS or different server like system. Thought, i think, running a full node wallet could be end user friendly with some changes in the current concept. Today a standard user can download a 1080p 10GB movie over iTunes (in background) and simultaneous play a CPU/GPU extensive 3D game on a standard computer. Why do people think (and it might is) running a full node is so painful? Mainly it could be because bitcoin-core has been focused on doing validation as quick as possible (okay for a server, not desirable for a wallet background service). I could see the following strategy: - - end user focused full node wallet would have enabled pruning by default (~2GB disk usage). - - throttled validation (flexible CPU usage, user selectable, maybe ~20% by default). - - throttled block download (bandwidth). - - SPV during catch up (initial sync as also when catching up multiple days because user/node was offline). - - Disable bloom filtering if there is enough bandwith, keep blocks for later validation. - - when node is in sync, switch from SPV to full validation (maybe maintain to lists/dbs of wtx or re-validate after full catchup and display potential conflicts). - - participate in p2p, but with limits/throttling (service limited amount of blocks, tx [TBD]). Why? - - This could increase the amount of participating full nodes while giving users more privacy and security. - - Create a counterweight against SPV/thin clients (avoid wallet development centralization, could be helpful once/if attacks agains SPV/thin clients are becoming real). - - Slowly complete full validation (can take ~1-2 weeks) and thereforce increase privacy (avoid bloomfilters) and security. What about SPV together with a full node? Sounds good in theory. But who can run a full node (see above)? How is the channel secured (against MITM, privacy) between the SPV client and the trusted full node? How hard is it to setup and maintain a secure tunnel between a smartphone SPV and a full node over the p2p (8333) channel? How about examine the mempool for fee calculations and (maybe) upcoming CPFP like approaches, etc.? How about smartphones? Obviously the above solution won’t probably work on a smartphone (to much bandwidth and CPU usage). But do you carry your whole saving in your physical wallet with you? Maybe a smartphone does hold keys which protects low value / daily spendings like a physical wallet (=SPV okay). My personal long term vision of that use-case is, that groups of people who trust each other (a family, etc.) might run one or multiple full node(s) on a hardened system (something similar to the bitnodes hardware) where the system could serve smartphones over something like a stratum server (electrum) or bitpays wallet-service does (index blockchain, additional wallet services). Every member still holds it’s keys but they trust the connected full node (full nodes does address index, balance calculation, multisig arrangements and maybe even coin selection). Since about one year i slowly work toward this direction. It took me a while to commit myself to a strategy (and i still shake from time to time). At the moment I am working on a wallet focused bitcoin-core fork with the ability to re-merge it to the bitcoin-core branch (keep the fork rebased). Long term goal is, to decouple the both (wallet / core) by using bitcoin-core as a library (static or shared) for the wallet side (which is possible already now) To myself: I work in the bitcoin-space full-time and completely independent (not employed or influenced by a bitcoin related company) with no business interest, though, i think the acquired know-how can be valuable within the next serval years. And i won’t have any regrets if my work turns out to be unless and ends up in trash. I have set up this mail to avoid parallelism on a works stream (if there is any). Of course i would really appreciate if other developers are willing to join the team by reviewing, concept critism or contributing code at https://github.com/jonasschnelli/bitcoin. Any forms of criticism and any ideas are highly appreciated. — /jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVyboPAAoJECnUvLZBb1PsgkkQAKySrksCclbfwIsf1L4Jwaxp nWmUhlXa3lIoxKG3eYZMPVugFX/LFKtmNqypQJ8whUjF2K5ZwIW1Boosl13cBkE9 2EIAMcBrpah0pwzomJ9ViLArl+7t6ksLR5qWJsgJsLnWlaW4c/1KwjGkYTZ6++VC 8O3M3HrdwT3fnrK35XJXTIhpFfRKRFrWcW98vMFt9xw7MUq+enhloGF6Nw4UiQbi nOV85YleBJEBU5cXuIOznG4EwHH77f8336+GY8d6mLCg7rKj7ZZWqqHztqEQf68Q mtwJhag3pxyW2jqb/fCxYD27oPqgMcLT1lyUobpzu7SrlKKmAIikf8uNU1+8rH+W U1C1IsWzvoPK7g7mqlmpk1/6kvlJOWNshTATfQS2A/hMB1Oec3zZTCz+P5S5g+F7 FT4tB2sR2nwGkWNVPNSs92o0f8y55/u+fAFcbmHkkNrfEt4IuMwsqJNW9i7GzU6b uOznq4ZgYw5OxUJh8uXLaA1OFIdPTEcTA4nNRSA7v6cRbfWeaCSGzafOYdGQKV2Y 5R7VCZJZe8ALzSUr03FsZ5bilcjdJ3ZyeQNikqeYnQLP+qoH6oRhDT0B2GI2E4+4 EvfIZCmaDxYG0FClWOQiiO0WeW2kNBWyD3tWCpM63ri//OnoN65NDKsbIpJ+oD8m OwxleWQP0eC/5knZSFwB =7CG9 -----END PGP SIGNATURE-----