Topic: Separate Bitcoin-qt/bitcoind into public daemon, wallet code and GUI (Read 908 times)

It would seem prudent to restructure the Bitcoin-QT/bitcoind implementation to have the following distinct components.

* A daemon much like the current bitcoind daemon but without any wallet code.  Notably everything in the process address space will be public information.
* Wallet code library and possibly daemon implementation.
* The GUI using the wallet library that connects to the daemon and launches it if needed.

Doing this has the following advantages
* Removing all wallet code and data from the core daemon that processes messages and tracks the block chain decreases the chance wallet data (private keys) will be compromised as the result of an exploit in any of the daemons other code.  OS file system security could be used to ensure the bitcoin message/blockchain daemon couldn't access any wallet files.
* The current implementation where the daemon and GUI run in the same process is not very conducive to multi user systems.  Notably each user that runs Bitcoin-Qt ends up with there own copy of the blockchain and I expect by default you can't run two copies of bitcoin-QT as different users on the same system at the same time (port conflict).  If the daemon was always in a different process (with very restrictive permissions) that the GUI connects to, it wouldn't be an issue to have many instances of the GUI running for many different users.  Each GUI instance would run as the appropriate user and only have access to the appropriate wallet files.
* The same multiuser ability can be extended to trusted networks so each computer doesn't need to run the full daemon just the GUI that connects to the daemon on a "server".
* The daemon can be run all the time and still appear to function as it does now.  This could be an installation option.
* Ensuring the interface between the daemon and GUI is clean and well documented will allow for more innovation in the GUI and daemon by allowing different implementations to interact with each other.  You shouldn't have to mess with or recompile the daemon to change the GUI.  Ideally this interface is standardized so completely different GUI and daemon implementations could be compatible with each other.

Let me know if this idea has already been discussed but I missed it or if there is some reason other that the work involved that its not done this way now.