Published on: 2014-06-25T05:43:23+00:00
In a discussion on June 24, 2014, Justus Ranvier and Wladimir debated the differences between full nodes and wallets. Wladimir argued that full nodes and wallets have different usage scenarios, with wallets being online as little as possible and full nodes being online 24/7. Justus pointed out that btcd had done this right, with the wallet daemon running constantly in the background like a full node. He also noted that there was no need for a one-to-one relationship between wallets and GUIs. Finally, Justus suggested that the wallet should not be running as much as it currently is.Wladimir has argued that full nodes and wallets have different usage scenarios. Wallets should be online as little as possible, whereas full nodes should be online 24/7 to be useful to the network. The author of the post believes that btcd has done this right. The wallet runs constantly in the background, like a full node daemon. However, the GUI (which is distinct from the wallet) runs as little as possible, indicating that there doesn't need to be a 1:1 relationship between wallets and GUIs. Finally, the post encourages supporting online privacy by using email encryption whenever possible and provides a link to learn more about it.The author of this message argues that there is a difference between what the core nodes should be like and what the codebase core nodes are built from must support. He suggests that with sufficiently modularized code, one can build a binary that does full verification and maintains some indexes of some sort. However, the author believes that what we push for as the core nodes of the network should aim for purely verification and relay, and nothing else. Despite this, the author acknowledges that people will do things differently if the source code allows it.In an email exchange on 24th June 2014, Tamas Blummer raised a question about the advantage of having services like exchange and payment processors talking via the p2p protocol instead of something more direct when both processes are controlled by the same entity. Wladimir responded positively to the headers-first approach and clarified that nobody would be forced to separate the code in a way they don't like. However, he acknowledged the need for modularity and competing codebases and expressed his reservation about the argument that indexes must be necessarily out of the core. He suggested that the "core full-node" should maintain a minimal and non-optimized mining functionality, even if it is only used for testing purposes. Nevertheless, he agreed with everyone that the wallet code needs to be separated.In an email exchange on June 24, 2014, Mike Hearn and Wladimir discussed the concept of a single unified program versus a "bag of parts" made up of specialized tools. While Hearn argued for a unified program that would automatically figure out priorities, Wladimir preferred the idea of specialized tools maintained by experts in each area, allowing for experimentation and competition. Wladimir believed that innovation outside of the strict consensus rules of the blockchain should be possible without bottlenecks or widespread agreement, including P2P message extensions. He suggested that successful experiments could be merged into Bitcoin core, but pre-assembled bags could still be offered for user convenience.Pieter and the author of the context agree on keeping bitcoind as lean as possible, which means maintaining extra indices for others does not fit in. The idea of an 'index node' is suggested to be a different approach. The goal is to make a p2p node as useful as possible within its resource constraints and optional advertising of new indexes is the way to go. However, the author questions whether having an RPC or new socket based method would be too complex for users who just want to help out the system. Therefore, a single unified program that automatically figures it out rather than expecting users to assemble a bag of parts seems like a more practical goal.In an email exchange between Jorge Timón and Mike Hearn, they discussed separating the wallet code from the full node. The qt-wallet currently does not support SPV operation, so complex work should be done after the wallet is separated. The first version of the separated wallet should be functionally equivalent to today's wallet as a full node wallet. Some steps on the path of bitcoind towards SPV are also useful in general. For example, headers-first allows parallel block download, which would solve a lot ofWladimir has suggested using peer-to-peer (P2P) primarily for a Simplified Payment Verification (SPV) client as the least surprising option. He believes that separating the wallet from Bitcoin's core code would result in cleaner and more modular software. The plan is for bitcoind to support SPV mode and an optional trusted core by RPC for mempool/conflicted transaction validation.
Updated on: 2023-08-01T09:38:04.693756+00:00