Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset.   Unless goatpig has a recommendation for this, I'm not sure I see a way around it.   I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.

Ugh.

Awesome!  I will add that to the troubleshooting page.  At least a couple problems people have had, turned out to be bitcoin.conf issues, but not enough that I remember it as a common troubleshooting tip.

"2x as likely to contain a bug" is really meaningless.  Both applications have been around for a very long time, and have been thoroughly tested by thousands of people.  Armory is used by some of the biggest bitcoin investors and holders, because it was created for exactly that purpose.  I tested the bejeezuz out of the wallet code before I ever released it for use, and that code continues to remain almost entirely untouched without issue, even after  almost 2 years.  So far there's never been a report of any problems losing coins that couldn't have been avoided if the user had made a paper backup (and tested it).   Make a paper backup and test it.   

You can make your own decisions about it.  But it's got a pretty solid reputation for being secure and robust.  What's not awesome about it is the time needed to get it running and the resources it uses.   So far, I've swept that under the rug as "the cost of security."  Luckily, a lot of the usability issues should be resolved that soon.  But it's not stopping people who really want to use it, from using it. 

I'm not convinced the URL registration is the issue.  It's probably what happens right afterwards.

I see the "bitcoind is no more" message which I don't even remember putting in there, and haven't seen that in log files recently (or ever).  I'll do some digging...

Have you been using (or able to use) Bitcoin-Qt or bitcoind by itself?  This might actually be a Bitcoin-Qt problem.  If you close Armory and run Bitcoin-Qt by itself, does it load and run fine?  Any error messages?   

It depends on the password size and the key-stretching settings.  Let's make some assumptions:

• You use default Armory settings, which means it takes about 0.25 sec per guess on an i5-2500K CPU
• The NSA has no real advantages or shortcuts -- no SHA512 shortcuts, no clue what your password is or might be
• The password is 12 characters long, including all uppercase, lowercase, numbers and special symbols... so the password has an alphabet of approximately 70 letters.
• Since passwords are usually chosen by humans (and not proper randomness), let's assume that your password is good but doesn't have full 12 characters of entropy.  Let's say 9 characters of real randomness spread across the 12 characters of password. (this is actually a tad optimistic, but we can scale the results based on any change in assumptions)
• Armory's key-stretching is designed to be GPU-resistant, since it requires 4-32MB of dedicated RAM per process/thread doing password checking.  GPUs normally get something like 1,000x speedup at password guessing, but we'll assume 10x here.

Then to guess the password on a single GPU, it would require:

70⁹ * 0.25sec / 10(GPUadvantage) = 1,008,840,175,000,000 seconds = 31,990,112 years

Okay, so 32 million years on a single strong GPU.   If we assume that they have 1,000,000 GPUs to throw at it, then it's 32 years to break that encryption using all of their resources for an entire generation of humans.  It's actually a bit longer if they don't know how many characters it is and have to search through passwords shorter than 12 letters.  That's fairly prohibitive, and requires the agency to divert all resources to you. 

If you up it to 16 characters with approximately 12 characters of entropy, then it goes from 32 years to 11,000,000 years.  At most points in this process, they have better things to do with their resources than attempt this.  In fact, they'd be much more likely to just go searching your house for paper backups or sticky notes that might just have the password on it, and then give up if they can't find it.

Just uninstall it from the Control Panel and install the new package.  That's it.  All your wallets and settings will be untouched through an uninstall-reinstall cycle.  And since the beginning of time, Armory has not [yet] modified the wallet design, so all your backups are still good, etc, even if you later go back.

Just updated the link above with all sub-projects built with the vs110_xp toolset.  I have no way to test it currently, so I'm looking at Dabs

Here's the link again:

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/ArmorySetup-0.89.99.8-beta_win32_xp.exe

Whoops, I just realized that I didn't build all the projects with the new compiler settings. 

I'm about 10 min late for something, so I'll have to do it right in later this evening.  Sorry about that!

Hey Dabs, try this out:

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/ArmorySetup-0.89.99.8-beta_win32_xp.exe

EDIT:  As for building on Windows, CircusPeanut prepared some instructions.  We have a few Windows guinea pigs testing it out for us right now, so we can iron out the instructions.  We'll post them on the website when we're done.  I'll make sure he adds the steps for WindowsXP to it (it's basically :  download and install VS2012 update 3, then select the vs110_xp toolset).

Update:  0.89.99.8-testing

https://bitcointalk.org/index.php?topic=299684.msg3439894#msg3439894

---

With respect to entropy:  I think it's justified to want to supply your own high-quality entropy.  If the real, analog entropy is generated properly, there's almost no reason for a reasonably-paranoid user not to do it, besides convenience.  It may not be substantially better than the system RNG, but it wont' be worse (again, if you do it right).  You immediately remove all uncertainties about the PRNG algorithms, etc, and know that you are producing analog, memory-less entropy that can't be reproduced no matter how broken it turns out the system RNG is.

As such, I approve using your own entropy as long as you have made the process as high-quality as possible, and you don't mind the inconvenience.  However, I also don't believe that it's necessary for 99% of users.  Possibly 100%.  But it doesn't hurt.  

Okay, I think lack of working on XP is expected.  I don't have the right compiler installed for it.  Maybe goatpig can repeat (for me, but also everyone who might want to compile it) what is needed to build with Windows XP support.  I sounds like it's not hard, I just have to have the right packages installed on my windows machine.   I think.

I forgot to mention that if you were previously having problems, you might have to start it with " --rebuild" to rebuild the database before the bug fixes become apparent.  Strong possibility you don't have to, but doing a " --rebuild" will also give you a chance to test the new speed in Windows.  Please let me know if it seems faster...

EDIT:  Alternatively, if you don't know what I mean when I say "start with --rebuild", you can just delete the databases directory in the Armory home dir.  It will rebuild the next time you start it.  You can find the databases dir at:

Windows:  C:\Users\<user>\AppData\Roaming\Armory\databases
Linux:  /home/<user>/.armory/databases

UPDATE:  0.89.99.8-testing

Windows:  download from my dropbox folder
Linux/OSX:  Checkout the "testing" branch

What's different compared to 0.89.99.5:
--Fixed a major bug which might be responsible for the orphan chain issues.  I'm not sure, because I haven't been able to reliably reproduce it.  But the bug I found could very well cause such issues.  If you had the "Marking Orphan Chain" issues, please try the new version!
--Windows appears to run much faster.  Now it only takes about 50% longer to do its operations compared to the Linux runtimes
--Closing the app in offline mode no longer seg faults
--Issues with uninitialized zero-conf transactions getting into the mempool have been fixed.  This does not fix the zero-conf-disappearing bug (I don't think).  That is still on my list to track down and fix. 
--Zero-conf-disappearing bug:  it is still a problem, but I have put in a fix that should cause it to correct itself on a restart.  If you can reliably reproduce that bug, please tell me if restarting fixes it. 

What's the same:
--Zero-conf-disappearing bug is still there. 
--Restarting Armory in the middle of the original DB build still resets the progress meter.  To be clear:  progress picks up from where it left off, it's just that the meter tells you progress between where it started and the end, instead of the overall progress, so it looks like it restarted.
--I had run into an unrecoverable "Cannot copy partial StoredTx" bug (or something like that).  Unfortunately, I destroyed the DB I had that exposed that bug, so I'll have to go hunting it down again.  Luckily, I got a lot of information about it before I did, so I might be able to hunt it down without catching it in the debugger.

Thanks again to goatpig for all his help in improving the speed on windows, getting the unit tests working on Windows, and getting a full MSVS debugging environment working when running the full app (I used to only be able to debug the pure-C++ unit tests projects, now I can debug a full instance of ArmoryQt).  And about 300 other little things. 

For reference, I do exactly this:  keeping a laptop in a safe deposit box.  I visit the bank and hang out in the privacy room for a while when I need to sign a transaction.  It's encrypted and has no battery.   The price for the larger box isn't a lot.  I think it's about $90/yr versus $50/yr for the smaller one.    Either way, if you're going to the effort of putting your laptop in a safe-deposit box, I"m sure $100/year isn't going to break the deal for you.

At my bank, the privacy room has an outlet.  It's because they have one of those calculators with a small paper/receipt printer in the room which requires power.  I don't know if that's normal, I didn't shop around. But, I made sure beforehand that the computer works with the power cable but no battery.   

I asked the bank manager if they had the option of requiring two signers at once to access the box (perhaps, to open a safe-deposit box for the company).  They misunderstood thinking I wanted multiple signers.  We later clarified they don't have any way to enforce having multiple people present to access the box, though they do keep strict records of exactly what time the box was accessed, and ID the person who accesses it (and the employee who helped).  Not ideal, but at least it still requires collusion of one of the signers and a bank employee in order for tamper evidence to be skipped/destroyed. 

Having the ability to put the wallet encryption key on a USB key is interesting.  I like it for the offline computer (for the same reason I like it for the full-disk encryption).  But for hot wallets, I'm not sure I like it as much.  It's a lot easier to write a process to copy key files every time new media is inserted than to install a keylogger remotely (though, both are still non-negligible risks).  If you do it, you'd have to make sure that removable media is thoroughly protected, so that only your user account can access it and no other system users (which is possible, but I don't think it's default, and may be inconvenient to setup and use).

(1) I said "mostly" for the exact reasons you just mentioned
(2) In the next post I retracted the statement because I wasn't thinking about the privacy aspect.  If I thought it was totally redundant, I wouldn't be doing it myself


Many encrypted OS solutions also encrypt the swap, and doing so will disable suspend/hibernate.  I recommend using that option.  Alternatively, it should be possible to setup the offline system without swap.  It will complain during installation about how important it is to have a swap partition, but I think it usually lets you do it anyway.  Given how little resources are needed for the offline system, I wouldn't think twice about disabling swap.  But I haven't actually tried this.

Duh!  Of course.  I forget the people care about the public information, too.  I think the full-disk encryption is still a good idea for security, but it obviously has big privacy benefits.

Thanks for the link.  That's close to what I used in the past, and I may use that technique for other things.  However, I'm not sure if it works for full-disk/OS encryption.  Can you use it with your home directory and/or OS such that the key needs to be present right after POST in order to boot?  I remember having to either type a password, or insert the USB key to boot my computer.  In this case, I'd want only the USB key.

Cool, I like it.  225 bits of entropy if your shuffle is perfect.  And a lot less noisy, too!

I actually made my own device, using my recent obsession with 3D printing:

http://www.thingiverse.com/thing:167019

I made this so you can roll four dice at a time without any ambiguity about ordering.  Though, my experience has shown that if you hold it only from one side, the die closest to you doesn't get shaken enough for full entropy.  I'm still trying to figure out how I would make this more robust to human error (though, the other three dice get a lot of rolling entropy and thus if you do 2x-3x the number of rolls you'd need if they were all rolled perfectly, you'll still accumulate plenty).

Extra credit:  have the offline computer encrypted using a USB key, instead of a password.   Your wallet on the computer is already protected with a password, and using the same password for the disk encryption is mostly redundant (though it's better than nothing).    I know it's possible to /dev/random data on a USB key, and have the bootloader use that as the FS encryption key.  But it's been a long time since I've done that, so I don't remember how.

It will improve the "hardness" of the system if it is stolen, as long as you don't keep the USB key with the laptop.  If they don't have the USB key, there's basically no way to even brute force the FS encryption.  If the thief gets both the key and the system, well there's still the wallet password that has to be found (unless you wrote the unencrypted key data to disk;  which should not happen with standard Armory operations, but it's nice to have the extra layer of protection).

If anyone has more details about doing this, I'd love to be reminded.  I've been meaning to upgrade one of my offline systems to that method, but been too busy to go figure it out again.

Personally, if you want to do this right without worrying too much, I would simply get a bunch of dice and collect 100-150 D6 rolls (that's 256-384 bits of entropy, if it was all perfect).  Make the process of ordering the dice rolls as deterministic as possible, to limit the amount of "human influence" on the results.  Just type them into a a python shell string hash256() the result.  Use that as your private key/seed. 

You only need 128 bits of real entropy for a secure private key/seed.  As long as there's no gross human influence the results (such as insufficient shaking/rolling, or selectively ordering the dice rolls), then you should easily get enough entropy out of 100-150 rolls.   And it should take you no more than 5 minutes.

You could do the FIPS thing, but that requires converting the result into an integer and applying the modulus, both of which may be beyond some folks in concept, or available libraries.  Doing a sha256²() or HMAC() is totally sufficient for converting arbitrary data to a private key, as long as that data has sufficient entropy.