MIME-Version: 1.0
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet
Precedence: list

--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">&lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;</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--