You will end up with a fresh new download starting at zero percent in the default location.  You can either start it with the --satoshi-datadir option, or you can start it regularly, and change the options to point at the non-standard location, then restart.  If you do it the second way, it will create the default --satoshi-datadir and start downloading.  I guess you could combine the two:  start with --satoshi-datadir, then change the settings to make it permanent.

I'm not sure a better way to do this.  I need to make the process mostly-transparent to new users:  I don't want to walk them through a confusing process when they don't even know what my program is or what Bitcoin is.  I'd rather it "just work".  And for users that have been using Bitcoin-Qt in the default locations:  well it should "just work" by picking up where they last left off with Bitcoin-Qt.  (this means that for switching from Bitcoin-Qt to Armory, it should be actually quite painless).

I was thinking of further branching the code based on distribution for stuff like this, but I'm not sure it's worth my time.  If you're in Gentoo, you are probably used to tweaking settings  OTOH, I guess I can just add /var/bitcoin to the search paths.  It's not like it will really slow anything down for anyone, searching one more directory, once each load...

For the permissions question, I assume you're talking about the .bitcoin/blocks/blk*.dat files?  If so then, yes, it will work.  Armory [theoretically] only needs read-only access, though I never tested it.  If I did it right, it should work fine.

Not necessary.  Though, if your Bitcoin-Qt home directory (-datadir) is non-standard, it might create one in the standard place and start redownloading.  You can change the settings and restart.  It will pick up where Bitcoin-Qt last left off.

Linux users:  Please help test!

https://bitcointalk.org/index.php?topic=156250.msg1655941#msg1655941

I'm working on the Windows side of it, now.  I'll update that post when its ready.

This is one of the two major upgrades I need in order for Armory to be usable to users with shorter attention spans.  When this is working properly, you will never need to run Bitcoin-Qt/bitcoind again.  Just start Armory and it will do the rest.  

The other major upgrade is the resource usage and load time.  Those are both getting knocked out with the blockchain management/DB stuff.  That is top priority after this (including not rescanning every time).

Updates in 0.87.99-testing (soon to be 0.88)

• Auto management of bitcoind: This most definitely will break on OSX... gonna deal with that this week.  What needs to be done should be fairly well-explained in the interface.  I will be adding a troubleshooting section to the website to catch the most common issues.
• OSX Package:  Finally a real OSX package.  So far, it doesn't appear to work on every system, but works very well when it does!  Auto-bitcoind is disabled, since bitcoind is not distributed for OSX.  I will be implementing a workaround for that in the near future!
• Notifications of new Bitcoin-Qt/bitcoind versions:  It should work with both self-management and auto-management of bitcoind.
• Windows code-signing certificates:  Just like my GPG keys, I have an offline code-signing certificate just for Windows installers/MSIs

• On-screen Keyboard for passphrase entry: You can now fool keyloggers by using an on-screen keyboard.  If you're ultra-paranoid (and ultra-patient) you can use a keyboard that is scrambled in a cryptographically secure manner.   Comes in "regular" and "insane" flavors.
• Clickable (?) objects: Yes, they finally do something when you click them (used to be just 1.5s mouseover)
• Reduced the number of windows you have to click through to execute an offline transaction.
• Created new Ubuntu-10.04-32bit offline bundle:  this includes the frag/unfrag scripts for Shamir's Secret Sharing
• Unicode Issues:  Fixed all show-stopper unicode issues (I think), and detect and warn about non-critical unicode issues.  

---

To use 0.87.99 (which will be 0.88 when it's released):

Windows 0.87.99 -- SIGNED
Windows users must first uninstall any previous version, before installing this one.
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99-testing_win64.msi
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99-testing_windows_all.msi

Ubuntu/Debian 0.87.99 -- SIGNED (alternatively, use the "testing" branch)
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99_amd64.deb
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99_i386.deb

Ubuntu Offline Bundles (now in 64-bit!) -- With Detached Signature
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/Armory_Offline_bundle_0.87.97-beta_amd64.tar.gz
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/Armory_Offline_Bundle_0.87.97-beta_i386.tar.gz

The first Mac/OSX Release!  (works offline, too!)
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99a_OSX.dmg
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99a_OSX.dmg.sig

I have GPG-signed the SHA256 hashes (use the .sig above, for the .dmg for OSX ... I have updated it since the hashes were signed)
-- https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.87.99_sha256sum.txt.asc

---

What I've done:

If you are running Bitcoin-Qt when you start Armory, it will now tell you to stop.  "Let Armory manage the Bitcoin software" is the default.  You will be told to either close Bitcoin-Qt, or change your settings (with a convenient button in the middle of the dashboard).   You can go into your settings and uncheck the box to carry on using Armory exactly as you used to.  Or you can leave it checked and just close Bitcoin-Qt/bitcoind.

If you do not have bitcoind installed or it is in a non-standard location, it will tell you to install it, or change your settings to point to where it is located.  If it's not installed, it will give you a button you can press that will install it for you.  I put a lot of time into this, and a lot of testing.  It works as expected in both Ubuntu and Windows 64-bit.  I need others to try it to tell me for sure.  There's also a button for killing bitcoin-qt/bitcoind if you happen to have it open when Armory expects to run bitcoind, itself.

By the way, I know the initial-sync time-remaining counter is out of whack.  Predicting the correct download time is surprisingly hard!  I will come up with a better way, that doesn't choke when bitcoind pauses/hiccups during download.  I made "8+ hours" the maximum, to avoid it saying "187 years" when this happens...

Please mention everything that doesn't look right.  Most likely, configurations/combinations of options that lead to a dashboard that doesn't say the right thing, or buttons missing that should be there, etc.  Try out the new settings (renamed from "preferences").   One thing I threw on top was added a permanent "--skip-online-check" to the settings.  Try that out, too.

---

To help test...
To help test, these are operations that should be supported:

• Fresh boot of online operating, never installed or run bitcoind/bitcoin-qt.  Install and run Armory.  Have it install bitcoind/bitcoin-qt for you.
• Bitcoin-Qt already running default settings.  Armory will complain and kill it for you if you want
• Bitcoin-Qt can't be found default settings.  Point to the right directory, or install it for you.
• Change settings to manage bitcoind yourself.  Bitcoind already running, everything is like before (but with a completion bar)
• Change settings to manage bitcoind yourself, but it's not running.  Just like before.
• There is no upgrade button yet, but there will be one in the some-what near future, now that I have all these signed installer links.  I might as well autodetect versions and add an "upgrade" button for both Bitcoin-Qt and/or Armory, as necessary.

I definitely like the "purity" of not having any references to existing currency systems.  But that would be ignoring reality -- just about everyone who uses Armory, cares about the value of BTC relative to their native currency.
 
I wanted to add something that wasn't just a hack.  When I get done some of my testing, I'll see how fast I can whip something out.  Or someone else could try it for me  Just look in ArmoryQt.py for "tabDashboard" variable, and see how it is implemented.  You can then add a "tabPulse" and throw it on top.  Then use some of the existing examples to figure out how to layout the tab.  Even if you get something ugly, it would be a lot faster for me to fix the layouts, than it would be to start from scratch.

At the very least, it'd be cool to have the a drop-down list for currencies, and then a label that is updated with the current price every 5 minutes.  It could even download the latest chart from...somewhere, and display it with price.  I'd like to have a newsfeed, too... but that's probably for another day!

You can post in the regular discussions thread.  Of course, now that this thread exists... it might become a place where people start posting...

I have an idea I've been pondering for doing exactly that.  It's not actually that hard, though I should probably put the API calls into a separate thread so that it doesn't slow down Armory if MtGox (or other exchanges) are being slow to respond.  That adds a little complexity, but not a lot.

This is the most basic rule of ECDSA -- use a different random number for each signature.  I'd say that this should be a very difficult mistake to make, but apparently Playstation 3 also had some under-qualified developers in this regard.  

It's nothing new.  It's just the risk of "rolling your own" when dealing with crypto algorithms -- you don't understand the importance of each step, or have any guarantee you did it right.

Even when you think you did it right, you're probably open to things like timing attacks -- where someone gets your system to sign a whole bunch of stuff and collects statistics on the time it took -- which reveals information about the private key.  Proper implementations avoid this.

Check out this bling!



Got another cert just for code signing that is kept exclusively offline, but I'm not sure I can use it for OSX builds without bringing it online, or getting an OSX system offline (which will complicate the release process, for sure).

It'd be awesome if someone could figure out whether it's possible to sign OSX *.app files using Linux... so far it's not looking promising, but I'm sure I'm not the first person that's wanted to do this.  It looks like it's possible with Windows installers using mono and/or osslsigncode.  I really want to be able to sign all installers from a single computer.

Bah!  This is python!  Python can do anything and everything.  It is very fast to search a variety of locations for the executable.  I just need a few of the most common ones and os.walk will take me through the directory trees looking for files that match my criteria.  I can set it to only go 2-3 levels deep and/or stop after 10k files searched, to avoid getting lost. 

And like Erebus said, if that doesn't work...

It is encrypted with AES256.  There's two distinct steps to unlocking your wallet:

• (1) Convert your password to an encryption key
• (2) Use the key to encrypt your wallet with AES256

Passphrase --> 32-byte AES256 key --> Encrypt Wallet

The encryption key is a full 32-bytes of data, which would be impossible to guess.  But your password/passphrase is much less than that.  So an attacker doesn't need to guess the encryption key if they guess your password -- so they just need to guess a bunch of passwords, run them through (1), and then check if it's correct.

Bitcoin-Qt and Armory both do this, they just use a different step-1:  X,000 sequential hashes, forcing the attacker to spend a full 0.1-0.25 seconds to check whether they got your password correct.  The difference is that the key-stretching used in Bitcoin-Qt only requires compute-time.  It only requires a few dozen bytes of fast-access memory to convert your passphrase to an encryption key, it just requires a lot of hashes.  Because of this, is very parallelizable -- an attacker with a bunch of GPUs having 2,000 threads each can get 100-1000x speedup compared to only using their CPU.

But Armory key-stretching (and scrypt-based algorithms) requires each thread to have access to megabytes of fast-access RAM.  Thus, you might not be able to put it on a GPU at all, or you would only be able to run 10 of those 2,000 threads at once.  In that case, you might as well just use a CPU.

[/font]

It sounds like there is not a deterministic way to build on OSX, so it won't require messing with gitian.   Is it possible to compile and include extra executables in the .app?  Will I be able to reference it by a direct path name?  (i.e.  /Users/LibraryApplications/whatever/bitcoind)

Given the high price of BTC these days, it looks like I only need to offer, say, 3 BTC as an incentive for this one  Again, it's something I have no experience with, but may be "easy" (easier) for others.

This is exactly why Armory uses a scrypt-like algorithm for its wallet encryption.  It does the 100,000 hashes of the passphrase, but requires them to all be stored in RAM at once, so you can do 100,000 table-lookups on it to get the final result.  This makes GPU-acceleration pretty useless for an attacker (GPU threads usually only have a tiny amount of fast memory, not megabytes).    That's why the Armory website advertises "GPU-resistant wallet encryption".  (for reference, it's called the ROMix algorithm -- found in the same paper as scrypt, it's just that ROMix is much simpler despite being much less flexible about compute-memory tradeoff)

On the other hand, if you forget your password, you likely remember enough of it that you may only require a few weeks of single-threaded processing to find it.  

So apparently Wired ran an article that was basically about "Cold Storage", and there was no mention of Armory anywhere!  How did that happen?!?

If anyone feels like donating a minute or two to "marketing", please visit the Wired article and upvote the comment by "Alan Reiner" (that's me!).  You can also simply respond.  Either way, it'll help push that comment to the top where it belongs!   You can use a facebook for google+ login to do anything on that page.

Sorry, I don't have a lot of time to respond to this right now, but I wanted to point you to the Make a paper backup! thread.  It is a little verbose, but so was your array of questions

Short answer:  if you never import keys, that paper backup is good forever.  Even if you use 13 trillion addresses, you'll still be protected with that backup (though the software might need to be adjusted to handle wallets with 13 trillion addresses...)

Distribute addresses like a maniac for 5 years.  HD dies, get 100% of your coins back with that paper backup.  The backup can be made at any time, but of course it is recommended to make it before you use the wallet so you are protected the whole time you are using the wallet.

Cold storage is for a wallet.  Put Armory on the offline computer, make a new wallet, export a watching-only copy of it, import that copy into the online computer.  Now you can watch your coins, distribute payment addresses, verify payments without any loss if your online computer is compromised.  And if you made a paper backup of that offline wallet, you are protected not only protected by the airgap, but you can recover from a hard-drive loss any time in the future.  Pretty sweet! 

EDIT: The last thing I didn't mention was that the paper backup is also useful to recover your wallet if you forget your passphrase.  Seriously, the paper backup is good for everything

Well, hopefully it won't be needed anymore.  I should have a proper, Class 2 code-signing certificate soon.  I assume that Apple trusts the same software as everyone else?  Or at least, it will present it with a non-scary warning (because it will now have my name instead of something else).

I approve of this message.  This is why Armory uses a different alphabet, and uses checksums.  Of course checksums are there for checking that data was entered correctly, but it also requires users to manually compute the checksums if they want to enter their own data.  It's a nice protection from people just cramming "aaaaaaaaa..." into the wallet recovery screen.

Of course, Armory uses waaaay more than 128 bits of entropy, but I'll be bringing it down to 128 or 160 in the next release -- I was thinking 160 because I wanted to give a little margin in case your system does not have a high-quality entropy pool at creation time.  This because I totally agree with ThomasV -- 128 bits is a nice, unbreakable value.  Maybe in 1000 years when we have Dyson spheres around a few different stars for the purpose of collecting energy to break my wallet, they might break 128 bits.  

Unfortunately, there will be no auto-bitcoind for OSX   Because bitcoind is not distributed with OSX, so I'd have to do Bitcoin-Qt, but that's even more of a PITA, when the user keeps closing it and Armory freaks out.  I could minimize it, but it won't be totally hidden.

On the upside, I'm just about done with identity verification and will have a code-signing certificate soon!  This means that I can finally release signed installers for both Windows and OSX.  It's just that OSX will be one step behind, still requiring manual bitcoind/-qt management...

I know I just finished a bounty for OSX, and I'm fairly certain I'll have a signed .app for it soon, but I am wondering if another bounty would be supported for a bitcoind makefile to give to Gavin.  He's against building bitcoind with the official releases because there's no straightforward way to do it, without static compiling everything into it, or making a separate .app which is not only extra work for something in low-demand, but kinda weird since it's a .app command-line applicaiton...?

If someone figured out how to static compile everything into one executable that could be thrown in the existing .app, perhaps we could hand him the Makefile and he could review it an add it.  I know it won't be easy, and that's why I think there needs to be a bounty.  Otherwise... I'm not quite sure how to proceed...

Just a teaser to show that I haven't totally been slacking (well, I have been busy, so I haven't been able to work on it as much as I wanted to):



I have been anxious to resolve the resource usage, but I was in the dead middle of this auto-management upgrade.  It's been a total PITA, but it will be totally worth it.  I'm convinced that many problems are due to bitcoind/-qt not being synchronized properly before people start it.  It sounds so simple, but people have very little patience... and this is the number one barrier between me and my non-Bitcoin friends who would otherwise try my program.  This can actually make using Bitcoin-Qt easier, as I give some explanation of what's going on, and what to expect.

And once I have this released, I'm going full-throttle into persistent-blockchain Armory.  This will come with instant-load after bitcoind/-qt is synchronized, and it should clear up a plethora of instability issues caused by fighting over the blkfiles with bitcoind/-qt.  And I wish I had a better way to refer to that software other than "bitcoind/-qt"...  (In the app, I now just refer to it as "Please download the base Bitcoin software from www.bitcoin.org").

Well, take a look around the program.  Especially in "Expert Usermode".  

-- Offline wallet interface
-- Watching-only wallets with offline wallets
-- Intuitive interface for sending from offline wallets
-- Deterministic wallets (only-once-ever-needed backups)
-- Print your backups directly to paper
-- Multiple wallet management
-- Key importing and sweeping (single keys or batches)
-- Coin control
-- Custom Change Addresses
-- Create Clickable Payment Request to copy into emails/webpages

And you turn it into a downside, but the fact that uses Bitcoin-Qt/bitcoind is a good thing if you are looking for ultimate security.  Multibit and Electrum focus on convenience, at the expense of security.  The gap isn't huge, but if you're dealing with large amounts of money, why wouldn't you take an extra step to get the extra security?