I just noticed yesterday that --datadir fails if the target directory doesn't exist yet.  Rather than bailing, it just switches to using the default directory.  We're still not sure exactly how we want to deal with that yet.

Besides that, I've been using --datadir constantly, and it works fine (for me)

The new torrent download takes me a couple hours.  But then it has to process the bootstrap file which takes a few hours.  And then Armory has to build its databases which takes another couple.  I think most people will have slower internet than me, but it will still usually take less than 8 hours for that bulk download.

The key point though is:  the torrent download guarantees you can max out your bandwidth during download.  When you download through Bitcoin Core, you are downloading from a random peer that might be slow, or periodically stop responding.  I heard the devs were working on a parallelized downloading to mitigate this problem ... well we basically implemented that for them by doing the torrent thing

Let me know how it goes!

You sound like a perfect candidate to try out the new BitTorrent download feature in the latest Armory testing version!

https://bitcointalk.org/index.php?topic=522866.0

It will download the bootstrap.dat file from BitTorrent, then bootstrap Bitcoin-Qt/bitcoind off of it.  However, it only works if Armory is managing bitcoind for you. 

If you already have part of the blockchain downloaded, I recommend renaming your .bitcoin directory so that Armory will start totally fresh.  If it doesn't work, you can move it back and resume your multi-week download. 

And for your information, I integrated torrent for exactly this reason.   I had a neighbor complain it took 58 hours to synchronize.  And recently, I've been annoyed at how long it takes just to "top-off" the blockchain when it's off for a few days.   At least while Armory requires running a full node, we had to make this easier...

Determining change outputs in a vacuum is challenging.  There's only so much you can do to take a given transaction, and figure out which output is the change, which is is the destination.  When you start messing with custom change addresses, etc, the existing algorithm certainly will get it wrong.  We're aware of that.

But there isn't much more we can do about that, unless we explicitly add an extra data store just to store those details when the transaction is made.  But even if we did that, it wouldn't help in situations where you have multiple nodes all watching a wallet, unless you explicitly try to synchronize that data between them.  I'm not sure there's really a robust & reliable way that doesn't involve a ton of extra complexity. 

Just use Help->Submit Bug Report :-)

Not sure why it sounds "dangerous".  It's exactly the opposite.  It lets you download the latest version and verifies all the digital signatures for you, so you don't have to install and figure out how to use GPG, and then find our GPG key and verify fingerprints.  (granted, you should do that the first time you get Armory, but after that assuming you got a good copy, you will always be able to get the next version with the same security but without any effort).  We are not implementing automatic updates yet.  We're simply providing a mechanism for downloading signed installers and checking the signatures for you.

Multisig is my top priority after this version is out.  Coming soon!

So far, everyone who has reported this "image not found" error on OSX is running 10.9.2.  I think.  Please tell me if you see this error and are not running 10.9.2.

The error is not a missing file, because the exact same package seems to work on other versions of OSX.  It's that the same dynamic object used by earlier OSX versions doesn't seem to be compatible with 10.9.2.  It's possible we just might need to build a 10.9.2-specific version.  Ugh! 

Go figure I bet it's finally working on 10.9.1 and then Apple goes ahead and makes yet another incompatible version!

Kind of.  The code is technically the same, I just pulled out the chunk that converts a seed into paper backup into a reusable function.  It's not much easier to access via command-line.  We actually used the technique with a deck of cards recently to generate some new wallets, and it turned out to be pretty darned easy if you were in linux.  You only needed to install the offline package into a live session, and then open a shell in the /usr/lib/armory directory. 

See post #7 in this thread.

If you don't use P2SH anywhere, it works fine.

If you use P2SH, it will likely "work", but the offline computer will show useless info for any P2SH addresses.  I don't recommend using it, since part of the security comes from being able to review the entirety of the tx on the offline computer.

Is it?  I don't see any attempts to open 0.90.99.X in that log file.   

Also, is it correct it's on a system with 512 MB of RAM?    Are you trying to run this online?  That might be challenging, regardless of the reason it's not loading.  Also, I notice it is XP -- has anyone else confirmed that the testing version runs on XP?

That happens if you use hundreds of addresses and then restore from paper backup.  Of if you use hundreds of receiving addresses but do no spending in that time.  But absent those conditions, you shouldn't ever have to manually extend the address pool.  If those conditions do match yours, that advice will work.  But very few people run into that, so it's not my normal first round of advice.

It sounds like this situation is a freshly-made wallet.  Have you used it for any other transactions?   Are you sure that the wallet IDs are the same?  Rather, are you sure you're creating the transaction with the same wallet as you have on the offline computer?

--test-announce is became irrelevant once I published the high-security-signed announcements.  Running with and without it should be identical.

If anything, run with --skip-announce-check to prevent any announcement stuff from happening.  But I suspect it's something else -- I'm pretty sure the announcement stuff fails gracefully. 

If Armory shows up in the task manager briefly, it's probably opening the log file and dumping errors before quitting.  You need to look at the log that it wrote to:

C:\Users\<user>\AppData\Roaming\Armory\armorylog.txt


Btw, about the filenames in the program files directory:  it's because you don't have file extensions shown.  That directory has files "ArmoryQt.exe.txt" and "ArmoryQt.exe".  But when you haven't told Windows to explicitly show you extensions, they chop off the .txt and .exe respectively in the file browser.  So the text file looks like a .exe and the .txt looks like no extension...

That just made me realize you could probably fool someone even moderately tech savvy, by giving them a file.txt.exe and they might double-click on without thinking, since it's "obviously" a txt file...

When you use an end-to-end application for handling transactions like Armory (instead of hacking together multiple tools, scripts ,etc), you don't have to worry about this.  You are talking about change addresses, and all that is handled securely and transparently by serious wallets.  Using manual tools where you have to think about these things can lead to lost coins.

Armory creates the change address for you from the same wallet that is protected by your paper backup, and automatically sends the change there.  It is usually hidden from you because it is an unnecessary detail, and doesn't require any action on your part.  However, if you examine the transaction info, you will see the change address in the outputs list, with the wallet ID next to it (showing you it's money coming back to your wallet, not going somewhere else).

Not necessarily.  The pay-to-revoke payment address may have different security properties than the signing key(s) being protected.  For instance, I have a single GPG private key for signing company software releases, but the payment goes to a 3-of-5 address controlled by the directors of the company.  Also, a compromised pay-to-revoke address (without the protected signing key) does not give the ability to revoke the key... it simply nullifies the advantage this scheme has over the way revocation is done now, but doesn't really make it any worse.

Though, if the attacker compromises the directors' 3-of-5 address, you are probably totally screwed in so many other ways...

Strange.  Does the announcement tab similar show nothing on Win7?  Or you just didn't get the popups?  There should be some messages in the logfile that start with "announcefetch.py".  Right now the first URL always fails, the second one [should] always succeed.

This is really off-topic for this thread.  You should be aware that my idea is not about protecting Bitcoins or Bitcoin private keys, but about protecting a private key that is used, say, to sign software installers, etc.

To be clear, this is just like deleting an encrypted file on your hard-drive.  You can still see the filename and know where the file is while it's encrypted, and you don't need to decrypt it to simply delete it or overwrite it with new data.

Arguably though, certain operations like that maybe should soft-require a password to prevent legitimate users from doing it accidentally.  But it's really only a soft-barrier:  there's nothing stopping you, an attacker, or malware from opening the wallet file and deleting that entry.

Just an update on this:  we believe that most of the crash-when-reach-99%-scanning problems are related to the same issue, and is resolved in the latest testing version:

https://bitcointalk.org/index.php?topic=522866.0

Please try it out and post here or there with your results.  We're pretty excited that we think we've isolated and neutralized this bug!  It would great to know if there's still cases that aren't fixed.

Uhhh, gonna need more details.   What OS and version? Did you build it yourself or use our package?