From f2d550dded85834d982a463fd8d6c5e6b925d230 Mon Sep 17 00:00:00 2001 From: Jeff Garzik <jgarzik@gmail.com> Date: Tue, 11 Aug 2015 11:46:25 -0400 Subject: Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet --- 9b/012238b167febbca9f0e302e4c2b9f597a7855 | 356 ++++++++++++++++++++++++++++++ 1 file changed, 356 insertions(+) create mode 100644 9b/012238b167febbca9f0e302e4c2b9f597a7855 diff --git a/9b/012238b167febbca9f0e302e4c2b9f597a7855 b/9b/012238b167febbca9f0e302e4c2b9f597a7855 new file mode 100644 index 000000000..f1fa1dd32 --- /dev/null +++ b/9b/012238b167febbca9f0e302e4c2b9f597a7855 @@ -0,0 +1,356 @@ +Return-Path: <jgarzik@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 34C68279 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Aug 2015 15:46:28 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com + [209.85.212.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4DFE1D5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Aug 2015 15:46:26 +0000 (UTC) +Received: by wicja10 with SMTP id ja10so80238850wic.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Aug 2015 08:46:25 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=Qsi7qdFBTm57EFtl09XhJvKntJU8NSPUBiy1OLGFtlw=; + b=g83S0S4C2XwbkjkKnUOUtn8qxLxYxbo/wBywoouN6wpVSqCs8UFik3J7nQ2L0qNyAr + vZIojbXBpA6YPJyXR0HeUZyMz1GK/rmsM6wgZU6gu3lrpK1/AZmum69WoNMqdN+Yr/74 + CQTo+82YAy4ZcIWkB5fXj14E0vYRDWxBDSvKvbwuAoEGMQNhozk2bOFWuiRVbU8ZcpW1 + vzqK3ix98J5QAfy9c1D/+rsiXjDBuoENUPLLh8e74QlavmpUR6gTcl9T+bZzmUfUMNhw + mRi1p4drKW5AQEBFKsBnaRAJYD+S1i5JopZsEWT9ZYi4EeWKv5ww8WRp49oJtTKA0noh + Wx5g== +MIME-Version: 1.0 +X-Received: by 10.194.176.201 with SMTP id ck9mr56584147wjc.108.1439307985338; + Tue, 11 Aug 2015 08:46:25 -0700 (PDT) +Received: by 10.28.140.196 with HTTP; Tue, 11 Aug 2015 08:46:25 -0700 (PDT) +In-Reply-To: <55C9BA0F.60408@jonasschnelli.ch> +References: <55C9BA0F.60408@jonasschnelli.ch> +Date: Tue, 11 Aug 2015 11:46:25 -0400 +Message-ID: <CADm_Wcb2CXLJjuO_7kTmAHKxYhSs53pjecQoWKfM7wKE4GsRdQ@mail.gmail.com> +From: Jeff Garzik <jgarzik@gmail.com> +To: Jonas Schnelli <dev@jonasschnelli.ch> +Content-Type: multipart/alternative; boundary=089e013d1eb4304928051d0b016c +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: bitcoin-dev@lists.linuxfoundation.org +Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 11 Aug 2015 15:46:28 -0000 + +--089e013d1eb4304928051d0b016c +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + ++1 Glad to see this work. + +The Bitcoin Core wallet is a bit neglected these days - maintained but not +advancing. + + + +On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> -----BEGIN PGP SIGNED MESSAGE----- +> Hash: SHA256 +> +> Hi +> (excuse my english; it=E2=80=99s not my native language) +> +> As you might noticed, bitcoin-cores wallet didn=E2=80=99t got that much f= +ocus +> 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=E2=80=99t 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 (=3DSPV 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=E2= +=80=99s +> 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=E2=80=99t have any re= +grets +> 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. +> +> +> =E2=80=94 +> /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 +> =3D7CG9 +> -----END PGP SIGNATURE----- +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--089e013d1eb4304928051d0b016c +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">+1 =C2=A0Glad to see this work.<div><br></div><div>The Bit= +coin Core wallet is a bit neglected these days - maintained but not advanci= +ng.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br= +><div class=3D"gmail_quote">On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli= + via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.= +linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or= +g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= +n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SI= +GNED MESSAGE-----<br> +Hash: SHA256<br> +<br> +Hi<br> +(excuse my english; it=E2=80=99s not my native language)<br> +<br> +As you might noticed, bitcoin-cores wallet didn=E2=80=99t got that much foc= +us<br> +during the last month (even years?).<br> +Wallet development has mostly moved towards SPV (bitcoinj), thin<br> +clients (Electrum), centralized web middleware (Copay, Greenaddress,<br> +etc.).<br> +<br> +Obviously this direction was highly appreciated by users who now can<br> +now run a bitcoin-client (SPV / thin client) on a smartphone or on a<br> +computer with tiny available resources.<br> +<br> +Full validation slowly gets a privilege of people who can manage to<br> +run bitcoin-core on a VPS or different server like system.<br> +Thought, i think, running a full node wallet could be end user<br> +friendly with some changes in the current concept.<br> +<br> +Today a standard user can download a 1080p 10GB movie over iTunes (in<br> +background) and simultaneous play a CPU/GPU extensive 3D game on a<br> +standard computer.<br> +Why do people think (and it might is) running a full node is so painful?<br= +> +<br> +Mainly it could be because bitcoin-core has been focused on doing<br> +validation as quick as possible (okay for a server, not desirable for<br> +a wallet background service).<br> +<br> +I could see the following strategy:<br> +- - end user focused full node wallet would have enabled pruning by<br> +default (~2GB disk usage).<br> +- - throttled validation (flexible CPU usage, user selectable, maybe<br> +~20% by default).<br> +- - throttled block download (bandwidth).<br> +- - SPV during catch up (initial sync as also when catching up multiple<br> +days because user/node was offline).<br> +- - Disable bloom filtering if there is enough bandwith, keep blocks for<br= +> +later validation.<br> +- - when node is in sync, switch from SPV to full validation (maybe<br> +maintain to lists/dbs of wtx or re-validate after full catchup and<br> +display potential conflicts).<br> +- - participate in p2p, but with limits/throttling (service limited<br> +amount of blocks, tx [TBD]).<br> +<br> +Why?<br> +- - This could increase the amount of participating full nodes while<br> +giving users more privacy and security.<br> +- - Create a counterweight against SPV/thin clients (avoid wallet<br> +development centralization, could be helpful once/if attacks agains<br> +SPV/thin clients are becoming real).<br> +- - Slowly complete full validation (can take ~1-2 weeks) and thereforce<br= +> +increase privacy (avoid bloomfilters) and security.<br> +<br> +What about SPV together with a full node?<br> +Sounds good in theory. But who can run a full node (see above)? How is<br> +the channel secured (against MITM, privacy) between the SPV client and<br> +the trusted full node? How hard is it to setup and maintain a secure<br> +tunnel between a smartphone SPV and a full node over the p2p (8333)<br> +channel? How about examine the mempool for fee calculations and<br> +(maybe) upcoming CPFP like approaches, etc.?<br> +<br> +How about smartphones?<br> +Obviously the above solution won=E2=80=99t probably work on a smartphone (t= +o<br> +much bandwidth and CPU usage). But do you carry your whole saving in<br> +your physical wallet with you? Maybe a smartphone does hold keys which<br> +protects low value / daily spendings like a physical wallet (=3DSPV okay).<= +br> +My personal long term vision of that use-case is, that groups of<br> +people who trust each other (a family, etc.) might run one or multiple<br> +full node(s) on a hardened system (something similar to the bitnodes<br> +hardware) where the system could serve smartphones over something like<br> +a stratum server (electrum) or bitpays wallet-service does (index<br> +blockchain, additional wallet services). Every member still holds it=E2=80= +=99s<br> +keys but they trust the connected full node (full nodes does address<br> +index, balance calculation, multisig arrangements and maybe even coin<br> +selection).<br> +<br> +Since about one year i slowly work toward this direction. It took me a<br> +while to commit myself to a strategy (and i still shake from time to<br> +time).<br> +At the moment I am working on a wallet focused bitcoin-core fork with<br> +the ability to re-merge it to the bitcoin-core branch (keep the fork<br> +rebased).<br> +Long term goal is, to decouple the both (wallet / core) by using<br> +bitcoin-core as a library (static or shared) for the wallet side<br> +(which is possible already now)<br> +<br> +To myself: I work in the bitcoin-space full-time and completely<br> +independent (not employed or influenced by a bitcoin related company)<br> +with no business interest, though, i think the acquired know-how can<br> +be valuable within the next serval years. And i won=E2=80=99t have any regr= +ets<br> +if my work turns out to be unless and ends up in trash.<br> +<br> +I have set up this mail to avoid parallelism on a works stream (if<br> +there is any). Of course i would really appreciate if other developers<br> +are willing to join the team by reviewing, concept critism or<br> +contributing code at <a href=3D"https://github.com/jonasschnelli/bitcoin" r= +el=3D"noreferrer" target=3D"_blank">https://github.com/jonasschnelli/bitcoi= +n</a>.<br> +<br> +Any forms of criticism and any ideas are highly appreciated.<br> +<br> +<br> +=E2=80=94<br> +/jonas<br> +-----BEGIN PGP SIGNATURE-----<br> +Version: GnuPG v2<br> +<br> +iQIcBAEBCAAGBQJVyboPAAoJECnUvLZBb1PsgkkQAKySrksCclbfwIsf1L4Jwaxp<br> +nWmUhlXa3lIoxKG3eYZMPVugFX/LFKtmNqypQJ8whUjF2K5ZwIW1Boosl13cBkE9<br> +2EIAMcBrpah0pwzomJ9ViLArl+7t6ksLR5qWJsgJsLnWlaW4c/1KwjGkYTZ6++VC<br> +8O3M3HrdwT3fnrK35XJXTIhpFfRKRFrWcW98vMFt9xw7MUq+enhloGF6Nw4UiQbi<br> +nOV85YleBJEBU5cXuIOznG4EwHH77f8336+GY8d6mLCg7rKj7ZZWqqHztqEQf68Q<br> +mtwJhag3pxyW2jqb/fCxYD27oPqgMcLT1lyUobpzu7SrlKKmAIikf8uNU1+8rH+W<br> +U1C1IsWzvoPK7g7mqlmpk1/6kvlJOWNshTATfQS2A/hMB1Oec3zZTCz+P5S5g+F7<br> +FT4tB2sR2nwGkWNVPNSs92o0f8y55/u+fAFcbmHkkNrfEt4IuMwsqJNW9i7GzU6b<br> +uOznq4ZgYw5OxUJh8uXLaA1OFIdPTEcTA4nNRSA7v6cRbfWeaCSGzafOYdGQKV2Y<br> +5R7VCZJZe8ALzSUr03FsZ5bilcjdJ3ZyeQNikqeYnQLP+qoH6oRhDT0B2GI2E4+4<br> +EvfIZCmaDxYG0FClWOQiiO0WeW2kNBWyD3tWCpM63ri//OnoN65NDKsbIpJ+oD8m<br> +OwxleWQP0eC/5knZSFwB<br> +=3D7CG9<br> +-----END PGP SIGNATURE-----<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br></div> + +--089e013d1eb4304928051d0b016c-- + -- cgit v1.2.3