let's see some log files then.

Will look into it.

New commit, calling out the testers =P

Most of the changes are stability and supernode improvements.

Core verifies blocks it downloads then commits them to the raw files. It doesn't verify the block was written properly, nor does it need to in order to function.

Your blockchain copy is missing blocks past the height Armory is stuck at. You have to redownload it.

The wording makes me feel a bit uncomfortable.

Let's make things clear. Armory is FOSS, the common sense implications are that you are using the software at your own risk and that you can't hold us devs accountable for snafus. You also didn't pay me for my consult on this matter so you can't hold me directly responsible if stuff goes stupid.

TLDR, I'm laying out my opinion, you figure out the rest for yourself.

That said, I think Armory gathers enough entropy to create root keys as is, and that the method you propose will not reduce entropy, and in fact increase it. I think the extra entropy is overkill in this particular case, and past 256 bits entropy, quality trumps quantity. But that's only my opinion and you should definitely go with what makes you comfortable.

Do with that what you may.

You could probably write a few thesis on entropy. Discussing it with the terms we are using is merely scrapping the surface of the underlying math. Simply put, the more entropy you feed a proper hash function, the more entropy your result will benefit of. However, due to the limitation of your final secret (here, 256bits), you should be more concerned about the quality of your entropy rather than quantity.


From the link:


I don't know where he gets the 0.6, I don't remember seeing that anywhere in FIPS 180-3, but then again I read that a long time ago so I can't tell whether the value is realistic or not, but for the sake of the argument, let's assume it is.

0.6 * 2^s is about 0.5 * 2^s.

0.5*2^s = (2^s)/2 = 2^(s-1).

So with with n = 256 and s >= 256, you will have at least 2^255 unique values from the hash-n of a value in the [0, 2^s] range.

The mouse data in this particular code is a pair of integers (x, y) that define the position of the mouse relative to top left corner of the dialog the position is retrieved from. For a dialog of size (X, Y), the top left corner is (0, 0), the bottom right corner is (X, Y).

In this particular case, the dialog is created with a default size so it depends on the desktop resolution and the default system font size, which influences the size of the elements within that dialog (and thus how large Qt is going to create it). Assuming a desktop resolution of 800*600, I believe the dialog could get as small as 300 pixels wide and 150 high. This gives us x E [0, 150] and y E [0, 300], so an average of 16 bits for the pair in some pretty bad conditions.


Timestamps are in the plain old UNIX format, i.e. the amount of time that has passed since Jan 1st 1970. I believe the timestamp is in milliseconds in this case (I would have to double check). The more significant bits of the timestamp won't change at all during this operation, so only the bottom few really matter for consecutive throws. If you take [3-8] seconds per throw and key press that's about 12 bits of entropy per, but assuming I messed up and the timestamps are in seconds, then you are closer to 6~8 bits on the span of 100 throws.

It's bad practice. If you can fix the issue by only changing credentials on a folder, that should be the solution you go for. Giving system wide privileges to the process instead is not an acceptable work around, rather a way to verify this is a permission issue.

Chances are you have to explicitly tell Armory where your new block folder is.

Start Armory with --satoshi-datadir="mynewpath".

Just nitpicking


It failed to change privileges on bitcoin.conf, most likely because you user doesn't have the proper credentials to change access rights on that drive.

There are a few solutions available:

1) Start Armory with admin rights (I don't recommend this)
2) Turn off auto bitcoind management and run BitcoinQt yourself.
3) Start Armory with --disable-conf-permis (https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L120). I don't exactly recommend this either
4) Give your user the proper permission. Right click on the D drive, go to the security tab, pick your user and give it full control over the drive.
5) Move your bitcoin folder into a path your user has full rights over (most likely C:\Users\*yourusername*)

Which is why the deck of cards is preferable.


There's about 16 bits of entropy in each mouse pos considering the average size of the dialog and that the position is relative to the dialog's top left corner and cannot exceed the bottom right corner. With the added timestamp, I'd say you get another 8 bits so that's ~24 bits per keystroke.

You are complicating things for no apparent reason. If you don't trust the software RNG, use a hardware one or dice/cards. Mixing them defeats the premise. You either trust the RNG or you don't. If you believe the software RNG is unsafe, why mix it with a safe source? Just use the safe source.

Nevertheless, you are also using the weirdest way possible to mix the entropy sources. Add a command line argument in armoryengine.py, something like --extranentropy. Pass in your external entropy as a hex string, load that into a SecureBinaryData object so that it is mlock'd then feed that through the extra entropy channel at wallet creation.

If that's too complicated, start some offline live instance of Linux, copy over Armory and the necessary packages (into the live ramdisk). Make sure no storage device (internal or external) are plugged for the good measure. Hardcode your extra entropy straight into the .py. Start Armory, create your wallet, write down the backup string, test it a couple times and shut down the machine. Voila.

Lastly, as picobit stated, it's easy to shoot yourself in the foot manipulating entropy on your own. Make sure you follow the dice roll/card deck instructions properly, and that you know what you are doing with the code. It's pretty easy to pass in an empty string for your entropy source.

You unlocked the wallet so it used this opportunity to compute missing private keys. Armory wallets derive the public key chain without the need to compute the relevant private keys beforehand. This is how watching only wallets function. Specific to our format, when you unlock a wallet (i.e. make the private keys temporarily "visible" to Armory), the missing private keys are computed and saved to disk along the relevant public keys.

As I said a wealth of different operations can modify a wallet file, but that does NOT explain your issue. Your issue is that your wallet went from hash1 to hash2 (nothing out of the ordinary), yet it went back to hash1 later on. Certain operations in Armory could result in that but the steps you describe does not include any of these.


etotheipi developed the wallet format and I did the recovery tool. We are the only 2 at Armory with lots of experience on this wallet format, and I don't expect he has a different angle on this. You should start looking at the state of your environment as well.

The data in the wallet can change for a lot of different reasons, but I don't expect anything short of user action can modify data then roll it back. Maybe your log file could yield some information of what happened, but at this point I'm not so sure Armory is the culprit anymore. Did you change permissions on the file maybe? You should try to reproduce the faulty hash again.

Used a different password the second time around?

Did you hash the wallet, the backup, or both?

You should turn off auto managed bitcoind until your system is stable.

You can force your block data path using the --satoshi-datadir command line argument.

This is a symptom of an unsync'd Armory.

Again, you want to start Core manually (look for BitcoinQt.exe). Let that sync all the way, then report here.

Tons of different operations will change the binary content of a wallet. From adding/modifying/removing comments, to generating new addresses, to spending coins, and so on.

A wallet should not change in between runs: if you turn off Armory, hash your wallet, don't run Armory for a couple days and hash the wallet again, you should expect the same hash. If you ran Armory in between, all bets are off.