What is the reason of separation into 2 programs daemon and GUI?

[Stn]

Is there any point behind that fact Bitcoin client supplied with two executables "bitcoin" and "bitcoind"? Why it could not be single module with both functionality? Technically it seems possible. User then could see output either on server's desktop or via RPC.

Sometime user can see is just dull daemon window on the server and rejection from RPC. It is not clear either network unreachable or daemon is syncing at the moment. Could be much more friendlier if user see that client is functioning and in what particular state.

[markm]

For one thing, a GUI client needs a GUI, which is a massive amount of overhead for machines that have no screen, no mouse, and no keyboard...

-MarkM-

[Revalin]

Have your cake and eat it too:  'bitcoin-qt -server'

[Stn]

Have your cake and eat it too:  'bitcoin-qt -server'

Thanks, so sweet!

[smtp]

For one thing, a GUI client needs a GUI, which is a massive amount of overhead for machines that have no screen, no mouse, and no keyboard...

And for the other thing? *fg*
Hmm .. you mean this GUI-overhead results in about, I guess, ~ 20% of useless allocated RAM, of the total bitcoin-qt client? *LOL*
What a huge waste of resources. :->>

I believe it was a historical design decision for "prettyness", because the old GUI (wtx) was simple relative independently coded from the remaining code - or the new GUI (qt) was independently coded such that it was easy to get a GUI-less client, too (in the case that in the future the GUI will be changed again to a different library/API) -- well, my speculations.

smtp

[markm]

Its not just RAM, its screen image, which can be scraped by keylog-and-screensrape malware; its keyboard and mouse input, which can be pirated by keylogger and mouse-emulator malware.

Its a massive attack surface best done without.

-MarkM-

[Killdozer]

What are the disadvantages? I don't actually know how much overhead the GUI has, but however much/little there is, what is the actual problem with having 2 versions?
Maybe you think that a lot of code has to be doubled, maintained in two places or so? This is of course not the case, the actual bitcoin core code is of course shared and only exists in one place (source file). Making 2 executables is just a matter of an extra project file, it is done completely automatically on full build...

[justusranvier]

Is there any point behind that fact Bitcoin client supplied with two executables "bitcoin" and "bitcoind"? Why it could not be single module with both functionality? Technically it seems possible. User then could see output either on server's desktop or via RPC.

It would be better to have more separation, not less.

Only one instance of bitcoind is needed per LAN and it should run all the time as a daemon. For shared machines it shouldn't matter which user is logged on, or if anyone is logged in. Clients, on the other hand, only need to run when you want to use them and should not be shared.

If Bitcoin-Qt was stripped of the networking and blockchain functions and just became a SPV client that connects to bitcoind, and bitcoind was stripped of all wallet management functionality it would be easier to define a protocol spec and develop alternate implementations.

[behindtext]

it is common to see the separation between the underlying daemon and a gui since really do different things. per other comments, not everyone who runs a node wants to run the gui on that same machine.

bitcoin-qt might use some resources on your machine but they're not substantial. markm's point about attack surface is definitely valid since a machine where a user might want to run a gui is necessarily going to be more vulnerable to attack due to the preponderance of "large" pieces of software that frequently run on a workstation, e.g. webkit-based web browser, gecko-based email client.

per the usual with *nix operating systems, tools are designed to do a few things well and the partition between bitcoind, which does not depend on qt (a large dep), and bitcoin-qt makes fine sense.

[markm]

Does *coin-qt even let you turn off the stupid notification stuff, tell it not to clutter your desk with icons/widgets, stuff like that? I recall when I did run it it was a constant source of pointless distraction whether from work I was trying to do on another desktop of the GUI on the machine or even just trying to catch some television while puttering on the computer at the same time.

Or I could be partway through writing a forum post and some stupid bid for attention would happen, as if I wanted to know every time any account of any of the umpteen coin types mined a block or had some other transaction happen.

GUIs are unfortunately hard to avoid nowadays for things like browsing but can be very annoying.

I have some stupid icon at top of screen right now that seems to be a link to a web page and right-clicking it has no delete option, lefclicking it tries to visit the page, and middleclick does nothing. There were two at one point and I got rid of one somehow by dragging it somewhere and dropping it but no idea why that worked - I didn't drop it in a trashcan picture - and dragging this remaining one didn't make it go away last time I tried. Last thing I want is to fill that bar with icons for bitcoin, namecoin, devcoin, groupcoin, ixcoin, i0coin and coiledcoin just because DiabloMiner is merged-mining on p2pool somewhere in the background (neither, thankfully, blipping icons at me).

I already shut down ppcoin, bbqcoin, geistgeld and terracoin to save some RAM, and that was with all of them being daemons not qt-GUIs.

-MarkM-

[2112]

What are the disadvantages?

bitcoind is a functional subset of bitcoin-qt: check the function ThreadSafeAskFee(). The version with the UI actually asks and allows yes/no answer. The noUI version always answers yes.

This design mistake is called "inversion of control" and it cannot be easily fixed without significant rearchitecting of the software. It has been discussed several times on this forum, search for "inversion of control". Many people proposed totally unworkable solutions because they didn't understand the difficulty of dealing with the described problem.

[justusranvier]

The easiest way to solve a difficult problem is to discover that you don't actually need to do it in the first place.

Bitcoind doesn't need the ability to generate transactions or manage wallets.

[2112]

Bitcoind doesn't need the ability to generate transactions or manage wallets.

On one hand this is true. On the other hand the core development team will do everything to make sure that this doesn't happen. Please see the posts of gmaxwell regarding Stratum & Electrum (not to be confused with Stratum mining).

Dream On!

[markm]

If bitcoind cannot do sendcoins on behalf of shell scripts, apps, other machines on the local net, other machines anywhere that are authorised, and so on, then a walletd would be needed...

-MarkM-

[justusranvier]

If bitcoiond cannot do sendcoins on behalf of shell scripts, apps, other machines on the local net, other machines anywhere that are authorised, and so on, then a walletd would be needed...

I'd call it bitcoin-curses, the command line complement to bitcoin-Qt. http://en.wikipedia.org/wiki/Curses_%28programming_library%29
 
Someone could even make a libbitcoin to store common functionality between the two clients that other apps could link to directly. Actually, it looks like someone has already done something like that already.

[markm]

Curses! Haha.

Yeah its all very well to rail against voodoo black boxes but on another channel I am really starting to see why FellowTraveler's goal for Open Transactions is to have it be "the" finance layer that anything on the machine that touches finance goes through.

(This will all just be "opentxs sendcoinstoaddress --blockchain bitcoin --address 1234dghdtjhj --amount 5.4321")

-MarkM-