At the cost of having to babysit users that don't know they have to start their node to begin with? And getting flamed for a regression? I can't tell if that's the lesser evil. The issue isn't auto bitcoind really, any experienced user will turn that stuff off, and the current code behavior is to ignore auto bitcoind mechanics if a node is already running locally.

The issue is "plug and play" users, who read no instructions (literally none), have little patience and are outraged that the software just doesn't operate with no effort on their behalf. There is no middle ground to satisfy these people. The UX either needs to be tailored specifically to them, or you have to accept a portion of your user base will be perpetually dissatisfied. I chose the later.

Do not take my tone as condescending. This is literally how a significant portion of the Bitcoin user base operates. These are customers that will swallow hidden costs for a tailored, smooth UX and view Bitcoin as nothing more than a Paypal competitor with promise of valuation. What they basically want is a web wallet. I do not intent to monetize Armory, therefor I view this group as a net negative.

There are plenty of light and web wallet solutions out there that cater to these users. I'm trying to fill the gap for power users and businesses. I'm not going to go out pf my way to make the onboarding easier for a set of users that I am not developing for. It will only result in a half baked solution that will serve nobody.

I agree that auto bitcoind was a mistake to begin with. It brought in a group of users that have no use for any of the features that sets Armory aside from its competition, while increasing the software's maintenance cost. I don't know that it is worth the time to prune this functionality now that I've changed it to just be a fallback mechanism. The notification flicker is a bug and I will deal with it for 0.96.3. The particular user insistently complaining about it either doesn't understand what false positive means, or didn't bother reading my replies. Experienced Armory users probably never run into this bug since they wouldn't start Armory on top of a node mid sync.

Now, I also intent to change the block data access from on disk to over the p2p socket. At that point, the P2P socket will be the only required interface to operate with your node, in which case auto bitcoind will be a whole lot less error prone.

If someone really wants to go out of his way to cater to plug and play users (I don't), he can run a supernode service for these people to connect to so that they may sweep their funds without the need of downloading the blockchain, and move on to a wallet that is more suited for their needs. I don't have the time to take care of this, nor do I want to deal with the group that's going to just piggy back off of the service and complain when I take it down after a while.