I had the same issue a few months back with both instances of Armory that I was running and couldn't find a solution.  Ultimately I had to copy the Armory private keys into Electrum and then send the bitcoin to other full-node wallets of mine.

I see you didn't get any replies.  So though I am a total newb at this, I'll share my experience thus far with Macs and maybe you can share back what you've learned since you posted 2 months ago.

I fist tried minergate.com's mac client and got the following results CPU mining XMR:

Harpertown 2.8Ghz 8 Core Mac Pro (4GB RAM) - 175H/s
Nehelem 2.8Ghz 4 Core Mac Pro (8GB RAM) - 85H/s
Core i7 2.6Ghz MacBook Pro (16GB RAM) - 75H/s 90H/s

In other words, totally not worth it.

I'm just now installing Ubuntu on the Harpertown Mac Pro and will try both Minergate and Wolf's if the Minergate hashrate under Linusx is lower than what reports for Wolf's have been here: https://docs.google.com/spreadsheets/d/1MI-ic0Os25hgGUImW54sUIjZY_pUNQNa_W8Se5pRGBs/edit?pli=1#gid=0

Edit: Unbuntu Minergate on Harpertown Mac Pro - 190H/s

The graph would be more informative if it displayed the data as percentage of Bitcoins outstanding instead of just the total number owned and if it excluded the addresses of services which might be holding bitcoin in custody for others.

At any rate others have noticed that the topic itself is demonstrative of a significant Bitcoin flaw:

https://www.reddit.com/r/Monero/comments/4ih4m0/another_missing_the_forest_for_the_trees_topic_on/

This appears to be a one time solution - you have to open Electrum this way through terminal everytime if you want to store your wallet file somewhere other than the hidden .electrum folder in user's home directory.  Is there a way to point the program to a wallet file in another location permanently in Mac OS (10.11.4 El Capitan)?

I think your core premise is flawed.

It seems to me that most in the community want Bitcoin to be a good form of money - and a good form of money is BOTH widely accepted / fungible / divisible / easily transferable ("everyday currency" features) AND durable / price-stable ("good store of wealth" features).

The two general quality sets are not mutually exclusive and a refined Bitcoin implementation can arguably do both with no need for running two blockchains.

I also think that you're confusing the investment function with the monetary function - which is to be a store of value / accumulated wealth.  The investment function is not about storing wealth.  You invest to increase wealth, and you take risk to do that.  The whole point of investment is taking risk and thereby capturing the return which is commensurate with the level of risk that you're taking.  If you simply want to store your wealth (accumulated value / excess productivity) then you don't actually want to take risk, you want stability of value.

Most current forms of "money" are poor stores of wealth because they have a near-zero marginal cost of production and will therefore be produced until they have no value - which is to say that they only become price-stable at near zero.  The point of central banking is to control that production via cartelization, but ultimately central banks can only really delay the endgame of the market value of the currency declining to its marginal cost of production.

Bitcoin potentially solves the "store of wealth" problem by having a significant marginal cost of production built into its protocol.  And if it can manage to become widely accepted then its volatility (risk) will decline substantially and it will cease to be a good/bad speculative investment vehicle leaving the door open for it to become a very good store of value.  The issue remains as to how it can solve its own "everyday currency" problems (in the specific BP101 case - easy transfer-ability) and that's what the current debate over block size is about.  Folks have different opinions about how transfer-ability might be threatened by either:

1. Large block sizes and the bandwith required to process them (and how that effects decentralization which might potentially effect transfer-ability) and...
2. The ability of the current protocol and fee structure to manage a large overflow of unconfirmed transactions in the Mem Pools of the various network servers.

Personally I have some non-trivial concerns about 1 and absolutely no faith in 2 so kicking the can down the road by increasing block size A LITTLE while the community develops a better long-term solution makes sense to me.  The problem with XT is that it increases the block size a LOT (thereby substantially increasing the risk of issue 1) and does nothing to solve the bandwidth/decentralization problem that will (hopefully) eventually affect XT as well.  It would seem that the proponents of XT either believe that cheaply available bandwidth will outpace the growth of Bitcoin over the intermediate term or that they don't really share the same concerns about centralization of payment processing that I and a lot of the community do.  

>

This can never work over the long run.  It will fail for the same reason that all socialist/communist schemes fail - hashrate costs resources.  If you create a system where resource/productivity investment is not rewarded based on a free-market curve, investment in resources and productivity lags behind he efficient frontier and generally declines until everyone is poor.  Attempting to "fix" that problem by setting an arbitrary minimum resource investment (presumably decided by some central committee) will forestall the ultimate failure of the system, but not prevent it.  Committees setting arbitrary investment/production quotas have historically proven to be horrendously unreliable market price setting mechanisms.

>
   

[/quote]
The disparity between the rich and poor with Bitcoin is by far greater than any fiat currency in existence.  It will not survive if this remains true.
[/quote]

Hmm, that air carries the sweet smell of opportunity.  Stop complaining and start offering some goods or services that the "rich" might wish to purchase and pay for with Bitcoin.

>

Last thing we should want/need is Bitcoin being used by large corps to pay wages.  The whole point of Bitcoin is to liberate money from the control of governments and central banks.  Inviting large companies to use it as part of our slave-wage system invites the regulation that is anti-thetical to Bitcoin's very raison d'etre.  If Bitcoin is to both survive and thrive, it'll be because it offers the freedom that the USD can't to those who yearn for that freedom.

As the yearners grow in number - and they most certainly will in these waning days of the empire - Bitcoin and/or its progeny will grow just fine.

Have patience, the end (this time around) of this unsustainable foolishness with fiat money is nigh.  No need to try and speed things up artificially.

>

 

After a couple another day of testing and experimenting I find that if I use the full text in your original post above Bitcoin Core goes online when you open up Armory (and only then), but can't sync for some reason.  Whereas if you just use:

listen=1

as the full text of your bitcoin.conf file Bitcoin Core goes online when Armory is open and everything syncs up.

Mac OSX 10.10.1
Tor Browser Bundle 4.0
Bitcoin-Qt 0.9.3.0
Armory 0.92.3-beta

You, sir, are correct.  Thanks for the guidance.  For all other Newb Mac guys the solution is as follows...

The Mac OS text editor is setup to operate with rich text and if one changes the bitcoin file extension to .conf from .rtf it won't change the format of the content, thus generating the above reported error.  Thus one must:

1.  Set TextEdit for plain text in the New Document pane of TextEdit preferences AND...
2.  Open the Save dialog, choose Customize Encoding List from the drop-down menu for Plain-Text Encoding, add Western (ASCII) as an option, and choose that option for saving the bitcoin.conf file in Users/<Username>/Library/Application Support/Bitcoin

The bitcoin.conf file you create/edit with TextEdit should contain the (ASCII) text suggested by BookLover in the first post of https://bitcointalk.org/index.php?topic=623868.new#new.

Answer for those who come after me (thanks to key help from picobit):

The Mac OS text editor is setup to operate with rich text and if one changes the bitcoin file extension to .conf from .rtf it won't change the format of the content, thus generating the above reported error.  Thus one must:

1.  Set TextEdit for plain text in the New Document pane of TextEdit preferences AND...
2.  Open the Save dialog, choose Customize Encoding List from the drop-down menu for Plain-Text Encoding, add Western (ASCII) as an option, and choose that option for saving the bitcoin.conf file in Users/<Username>/Library/Application Support/Bitcoin

The bitcoin.conf file you create/edit with TextEdit should contain the (ASCII) text suggested by the OP in the first post of this thread.


   

Thanks for the tip picobit, but my Library isn't hidden (I unhid it a while ago) and having used the bootstrap.dat method of downloading the blockchain, I had already discovered HardDrive/Users/Username/Library/Application Support/Bitcoin, but there was no bitcoin.conf file there (or in any of the sub-folders).  I created one anyway using Text Edit and included a few versions of the recommended settings (including listen=1).  And I made sure to kill the .txt extension on the filename so that the extension actually was .conf.  None of that worked, it just left me with the following error message when opening Bitcoin Core:

"Cannot parse configuration file: the options configuration file contains an invalid line '{\rtf\ansi\ansicpg1252\cocoartf1343\cocoasubrtf160'.Only use key=value syntax"

...and then quits out of the launch process.

I'm running 10.10.1.

Thanks,
NBTCG

This setup does not seem to work on Mac OS.  Having followed the above guidance, Bitcoin Core returns the following error on launch:

"Cannot parse configuration file: the options configuration file contains an invalid line '{\rtf\ansi\ansicpg1252\cocoartf1343\cocoasubrtf160'.Only use key=value syntax"

...and then quits out of the launch process.

Oh yeah, I forgot to mention that Amory was connecting fine before I routed Bitcoin Core through the Tor proxy, which is now 9150 BTW.

 

So, obviously I'm a newb.  Please forgive that.
I've searched both here and elsewhere on the web and not found a clear answer to the following.  Please forgive that.

How the heck does one get Armory into Online mode via Tor in the Mac OS (in clear, easy-to-understand terms)?  I have my crayons ready!

The only fixes I've seen somewhat clearly delineated pertain to setting "listen=1" in the bitcoin.conf file, which I can't find in the Mac version.

I (finally) have Bitcoin Core v0.9.3.0 synched and set up to run via the Tor Browser proxy and it actively connects to the network and syncs the latest blocks.  I have Armory 0.92.3 setup with Enable settings for Proxies/Tor checked and I have tried it with Skip online check on startup enabled and disabled but the result is the same, all Offline Mode all the time.

I've seen posts where others ask this question, but only one where the user asked specifically about the Mac OS fix, and it basically went unanswered.

Could use some help here...

Thanks,
NBTCG