Future Of Bitcoin-Cores Wallet [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-08-11T15:46:25+00:00


Summary:

The Bitcoin Core wallet has seen a shift in development towards SPV, thin clients, and centralized web middleware, leaving the full node wallet with less attention. However, Jonas Schnelli proposes changes to make running a full node wallet more user-friendly. His suggestions include enabling pruning by default, offering flexible CPU usage, throttling block download bandwidth, participating in SPV during catch up, disabling bloom filtering, and switching from SPV to full validation when the node is in sync. Schnelli believes that implementing these changes would increase the number of participating full nodes while providing users with increased privacy and security. This approach would also serve as a counterweight against SPV/thin clients and avoid centralization in wallet development. While Schnelli acknowledges that this solution may not work on smartphones due to bandwidth and CPU constraints, he believes it could be effective for groups of people who trust each other.Schnelli has been working towards this direction for about a year and is currently developing a wallet-focused Bitcoin Core fork. His ultimate goal is to decouple the wallet and core by utilizing Bitcoin Core as a library for the wallet side. He invites other developers to join the team by reviewing concepts, criticizing ideas, or contributing code via GitHub.In a 2015 email exchange between Mike Hearn and Jonas Schnelli, they discussed the needs of bitcoin wallets. Hearn commended Schnelli's analysis but proposed a slightly different approach. He suggested supporting serving of Simplified Payment Verification (SPV) wallets from pruned storage, which would require protocol upgrades and Bitcoin Improvement Proposals (BIPs). This would benefit all SPV wallets, including those on mobile phones. Hearn also proposed creating a desktop wallet app based on bitcoinj that contains a bundled bitcoind. However, Hearn's proposal does not fully align with Schnelli's original post, which advocated for a single set of reference implementations for different components. Without eliminating bitcoin-qt in its current form, Hearn's proposal may not fully meet the spirit of Schnelli's recommendation.The message introduces an alternative approach to serving SPV wallets from pruned storage. It suggests creating a bitcoinj based desktop wallet app with a bundled bitcoind that syncs two wallets simultaneously: one from the P2P network and another from the local bitcoind via a local socket. The app would switch between using the wallet synced to P2P and the wallet synced to localhost when the latter is fully caught up, alerting the user if there are any discrepancies. This approach offers advantages over the current one, such as instant and transparent switching between local full-security mode and remote SPV security, which is beneficial for laptop users who do not run a local node all the time. Additionally, working with modern JVM tools and languages is more efficient than working with C++. For those looking to run a home server, bundling Tor and auto-registering a Tor hidden service is suggested. This would allow for defining a QR code standard to pair a wallet to an onion address, enabling any bitcoinj based wallet to sync to it. Furthermore, this setup allows for the use of a Bloom filter sized to give virtually no false positives without requiring additional indexing.Overall, the author highlights the lack of focus on Bitcoin Core's wallet development and proposes solutions to make running a full node wallet more user-friendly while increasing privacy and security. They discuss the limitations of smartphones in implementing these changes but suggest alternatives for groups of people who trust each other. The author is actively working on a wallet-focused Bitcoin Core fork and encourages collaboration and feedback from other developers.


Updated on: 2023-08-01T15:07:14.318292+00:00