Jeff Garzik [ARCHIVE] on Nostr: đź“… Original date posted:2015-08-11 đź“ť Original message:+1 Glad to see this work. ...
đź“… Original date posted:2015-08-11
đź“ť Original message:+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 at lists.linuxfoundation.org> wrote:
> -----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-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/b14d6491/attachment.html>;
đź“ť Original message:+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 at lists.linuxfoundation.org> wrote:
> -----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-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/b14d6491/attachment.html>;