From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 34C68279 for ; 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 ; Tue, 11 Aug 2015 15:46:26 +0000 (UTC) Received: by wicja10 with SMTP id ja10so80238850wic.1 for ; 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: From: Jeff Garzik To: Jonas Schnelli 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
+1 =C2=A0Glad to see this work.

The Bit= coin Core wallet is a bit neglected these days - maintained but not advanci= ng.


On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
-----BEGIN PGP SI= GNED 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 foc= us
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 (t= o
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).<= br> 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 regr= ets
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/bitcoi= n.

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/mail= man/listinfo/bitcoin-dev

--089e013d1eb4304928051d0b016c--