[bitcoin-dev] Future Of Bitcoin-Cores Wallet

* [bitcoin-dev] Future Of Bitcoin-Cores Wallet
@ 2015-08-11  9:02 Jonas Schnelli
  2015-08-11 11:03 ` Mike Hearn
  2015-08-11 15:46 ` Jeff Garzik
  0 siblings, 2 replies; 4+ messages in thread
From: Jonas Schnelli @ 2015-08-11  9:02 UTC (permalink / raw)
  To: bitcoin-dev

-----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-----

^ permalink raw reply	[flat|nested] 4+ messages in thread