Oh, I forgot about the building-from-source page, there.  I updated the "Get Armory" page to link to one of your posts, but that should be updated as well.  I'm wondering if there is a more auto-up-to-date way we can have your solution linked from that page.

Also, I should investigate if there's a way for me to "approve" of a particular version of your build scripts.  Perhaps, a "formula" that I can manually verify is getting the code from github, and compiling everything from brew, and then put my GPG signature on it.  Not that I don't trust you, but I'm sure that you understand I don't want to sign a script that has an arbitrary download link on it that could be swapped out from under me/you/us (besides github links).

Or maybe you could help figure out a way to bundle it in a more-convenient way.  It's a lot easier for me to verify a solution, than it is to come up with it from scratch...

Master branch is the correct place for it.  That's intended to house only the most stable releases.  All other intermediate and feature-testing versions will always be on a branch.  It just might be worth documenting how to modify it if the user wishes to switch to a different branch.

Also, I'm not sure what needs modifying in the instructions...?  HEAD on Master is actually identical to v0.85-beta, I just happened to tag it before I did the merge threading->master but after I merged master->threading (so they are the same).

There's already a tag for "v0.85-beta".  Though I accidentally tagged it on the threading branch, I don't think that matters.  Simply referencing that tag should get you there, regardless of what branch you're on.

I'll throw that into my next update, since it clearly improves the situation for some users, without any risk of harm (as far as I can tell...).  I mean, as a band-aid until I get official support throughout the app.

Are you in Linux or Windows?  If you are in linux, you could modify the code yourself, to remove the one offending line (well, change it).  It's the same line as you see the error:  first try changing it from "str(...)" to "unicode(...)".  If that doesn't work, then just remove the line entirely and change it to "txtime='0'".  That second one should definitely work...

The new wallet needs to support unicode strings, but I will be going through and updating ALL of Armory for unicode support.  I should've done it from the start, but I wasn't really familiar with unicode when I started... (yes, silly American...)

Is the reference to the specific version necessary?  "v0.85-beta"?  Couldn't you just use "master", and then the ebuild will always access the latest version only?  For reference, the master branch is specifically, only for final releases.  All development and testing versions stay on their branch until it's ready for release.  In fact, the act of merging it into master is what notifies users that an official new version is available:  the software checks the master-branch copy of versions.txt to determine the latest version.

Oh, the img directory does matter here (though it could be separated out...)

In dpkgfiles/postinst, here are the 6 lines that are run to setup the icons:


So it registers the icons with xdg-icon-resource using the names "armoryicon", "armoryofflineicon" and "armorytestneticon", and then references those names in the .desktop files.  That's the way I determined was the "correct" way to install a program on a Linux system (at least, Ubuntu/Gnome).

One of the reasons why Armory has been so "delightful" for users to compile is that I don't rely on any particular versions of the underlying packages.  Rather, I only use features that have been a stable part of those packages for a long time, and should be in all modern versions.

There are .desktop files in the dpkgfiles directory. 

As for CXXFLAGS and MAKEOPTS -- I'm not very good with makefiles.  I put together whatever I could to make it work.  If you have recommendations for improving it, or making it more versatile, I'll be happy to update it.

Armory runs from:

-- All *.py files in the base directory
-- _CppBlockUtils.so 

CppBlockUtils.py, _CppBlockUtils.so, and qrc_img_resources.py are created from the compilation procedure.  That should be all you need.  I just noticed that I packaged the "img" directory, but it's not necessary:  all the img files are encoded into the qrc_img_resources.py file.

Recompile the C++ utilities.  That's the error I see when users upgrade the python code (via git pull), but don't recompile the C++ changes.   (just 'make' from the base directory)

Ahh, unicode!  I haven't gotten around to making Armory unicode-friendly... but that is part of the new wallet design, and I'll be upgrading the entire application, with it

N.Z. -- I'm uncomfortable with adding watch-only addresses to watch-only wallets.  It makes it way too easy for someone to plant an address in your and then pay you to that address making you believe you've received coins.  However, I do want to give users some way to do it, I'm just not quite sure how to implement it, yet.

Even if there's not a developed web-of-trust system for GPG available, technically-savvy people still use GPG successfully.  I agree that such users should have the option to exchange/verify public keys out of band, to their own comfort level, and rely on that for signing invoices.  As long as all parties agree.

Is it?  What if you want your watching-only wallet encrypted but you don't have disk encryption setup?  What if you don't know how to setup disk encryption?  Wouldn't the same argument apply to the private keys, too?

Tell me if I'm wrong, but I think there's another key advantage (but I don't know much about the way these things are implemented).  If you use FS encryption, then once you've booted and your OS has requested and unlocked the filesystem encryption, then anyone who gains access to your system while it is running will be able to read that file, even if they got access to your system remotely (the OS will decrypt for them).  But if it's done at the application level, then the file will always be encrypted, and the only way for them to get the info will be to pull it out of your memory space.  I'm pretty sure that is "difficult."  But I don't know for sure...

N.Z. -- I actually did put the comments into the mouse-over text for each address, though I realize it's not ideal.  I didn't want to bloat the interface with all comments visible, but maybe I should try it and see...

I'm not sure what you mean about the "from address(-es)"   You can already double-click on the transaction in the ledger and see all the inputs and outputs -- which includes the funding addresses.  It won't tell you the list of addresses you had in the coin-control pool, but I don't see why one would need that.

I was not aware about the -listen command for bitcoin-qt for Tor.  I should put a comment about that somewhere...

I have tried to add a force-zero-fee option to the interface, but it doesn't actually work.  The problem is that Armory relies on Bitcoin-Qt/bitcoind to forward the transaction to the rest of the network, and if you're using stock bitcoind/-qt, the tx will be DOA.  There's no way to push it through, unless you copy the raw transaction and submit it to a node/miner that will take it.

One day I'll get on the translation train, but it will probably be a mess, because I have so many dynamic messages in the program.  Also, I'll need to support unicode first...   (but that's coming with the new wallet file)

Send me a testnet address, I'll send you some testnet BTC

And thanks to whoever just donated e BTC.  Thanks for not sending e^ipi

Another idea was just proposed to me, which I really like.  Out of scope for the first two ideas I presented, but completely relevant for a new wallet design:

Encrypted watching-only wallets

Some users have expressed concern that, although their BTC is safe if their online laptop is stolen because they keep their coins offline, the person that stole their laptop now knows their identity and the fact that they own $50k in BTC.  It would be best if the thief had no information at all...

As such, I'm thinking I could add an extra layer of encryption, to encrypt the public keys, addresses and transaction IDs stored in the wallet.  This "outer" encryption would use the same encryption scheme as the one used for private keys, but it would only have to be entered once when the app is started and would have no timeout .  This means that the data is always stored on disk encrypted, and the decrypted version only exists in RAM.

It would also be nice if all such wallets (per-computer?) had the same encryption.  So if you have multiple wallets, you still only type your passphrase once.  I can see it getting out of hand when you have multiple devices with different addresses, and then start juggling wallets around.  But there's only so much I can do about that...

Cool script.  I wasn't aware of blockchain.info's service.  How does it work exactly?  You give them an address you want the money to end up at, and they give you an address to which you can send coins and they will eventually be forwarded there?  How long does it take?

For anyone wondering, I just went through the script and it looks like a variant/mod of the extras/cli_sign_script.py that I added to the project recently.  It uses the Armory libraries exactly as they are installed/compiled, to access your wallets, find your coins, get forwarding/anonymizer addresses from blockchain.info, and then constructs an unsigned transaction for it.  I can't vouch for whether it works, but it very much looks like how I would've written it    (but I didn't write it)

So in talking with some users about the new wallet format, an idea came up:  what about encrypting the watching-only wallets?  And giving the option to encrypt even the public data in an encrypted wallet?  Perhaps the wallet is on a laptop and the laptop gets stolen.  The person can't get your $100k in BTC savings, but they now have your identity and know you have $100k in BTC savings...

I'm thinking that it could be implemented by encrypting, basically all the fields of the wallet, the same way as the private keys are encrypted.  When Armory opens, it will request the passphrase for the outer encryption, and give that key a lock-timeout of inf.  So the wallet will be accessible as long as Armory is open, but if it is closed (rebooted), the wallet will be inaccessible.  I'd prefer the outer encryption be a different key/passphrase than the one protecting the private keys, but I don't know if that would just be a P.I.T.A for the users (they can decide for themselves, I guess).  Really what this does it makes sure your unencrypted wallet information is only ever stored in RAM... it's only ever written to disk encrypted.

I think I like the idea, I just don't know how I want it implemented... perhaps a single password for all your wallets, rather than per-wallet?  That way, if you have 10 different wallets, you won't have to type in 10 passwords everytime you start Armory...

Glad you like the coin-control  I'm quite happy with the way it turned out!   K1773R:  have you tried it yet?  Does it satisfy your use case?  Or are the other features you were looking for in "coin control"?

By the way, I just implemented coin-control in Armory (not released yet, but soon).  And I discovered a good use for it:  cleaning up BTC crumbles in my wallet.  For instance, I just select all addresses that have balances with more than 2 decimal places, then I create a transaction sending their combined balance:  the integer part goes back to me, the non-integer part gets donated to another project.   Then my wallet is a ton cleaner (its balance is 28.15 instead of 28.37302811).  I just started doing this with each of my wallets and it made me think of this thread:

(1) The recipient of my transaction is being sent an output with 8 decimal places, the change has zero decimal places -- the exact opposite of what you would expect of a normal transaction
(2) Future transactions will be much cleaner in terms of decimal places, because when I pay someone 10.1 BTC, my change is 18.05 BTC, which is fairly indistinguishable.  
(3) Not that it matters to determining change, but I think it's good for the network (albeit, very mildly) to be sweeping up the crumbs like that.

I suspect, when I do release coin control, there will be other users doing the same thing, further complicating anyone's efforts to determine what is the correct change address. 

Oh yeah, it has been merged.  And then "coincontrol" was branched off of that.

P.S. -- Whenever you get in-program notification that a new version is available, it only because it was merged into master.  The URL Armory uses for checking for updates is:

https://raw.github.com/etotheipi/BitcoinArmory/master/versions.txt