It isn't a thing. WO wallets cannot currently be encrypted, and they only carry public data.

wallet.dat is Bitcoin Core's wallet format, which Armory does not use nor depend upon. Loosing Core's wallet.dat is an issue, as those carry private keys.

Armory's .watching_only.wallet files only carry public data. Compromising this file will leak your privacy. Any attacker can also choose to swap addresses in that file for his, so that you would serve his addresses instead of yours to receive payment.

Armory checks the consistency of all public data in wallets at start to prevent this sort of attack vectors (and data corruption in general, never know when a disk/stick of ram might fail).

Are you using auto managed bitcoind? Are any STDERR entries in your log file?

It's ok to distribute binaries as long as you attach the signed hashes file.

I'm not sure where you come from or why you think you have a leg to stand on in this matter.

If you've run Armory 0.92 or later, you have run my code. I've contributed over 2/3rd of the public code changes since 0.92.

0.93 is essentially my solo work, the other 5 devs were busy with closed source enterprise code. I was the defacto open source maintainer for over a year before ATI shut down development. If you had participated to the 0.93 and 0.94 testing phases you would have known that.


As for this question. Again, this is an open source project, (now 100%) community managed, so your best alternative is to read the code and build it yourself, or at least find a member of the community you trust that does that for you.

For what it's worth, I have yet to submit a commit that touches crypto or wallets in a significant way. You can verify this by checking the commit history on PyBtcWallet.py, PyBtcAddress.py, MultisigUtils.py and Transaction.py in the armoryengine folder (https://github.com/goatpig/BitcoinArmory/tree/master/armoryengine)

The EncryptionUtils.h/cpp files and the entire cryptopp folder are untouched as well. You could hash these and verify them against the code in 0.93 if you don't like to go through commits.

As for the new wallets, I'll keep them in separate code files and let both the old and the new format coexist in Armory for quite a while. I have no need to force users onto the wallet format I'll write for BIP32/44 support, nor do I want to blur the change history in the code base.

While it's fairly easy to verify by yourself that I haven't touched any of the crypto sensitive code in 0.94 and upcoming 0.95 (most of the changes are performance and paradigm changes around the DB, the blockchain parser code), you should review or get someone to review 0.96, which will introduce the new wallet format.

This version will have significant amount of new code dealing with crypto. However it will coexist for a while with the untouched 0.93 wallet format, so you can choose to ignore those for a while as long as you don't create a wallet with the new format (I don't intent to remove any of the old format functionality for a while, rather slowly deprecate them).


My preferred route is to split Armory into a set of stand alone libraries. I will start with the crypto code, i.e. isolate cryptopp and EncryptionUtils.h/cpp in its own repo, move to cmake for makefiles/msvs projects and dynamically link to it.

Since that will be all C++ with no need for C++11 support, it will be the first candidate for deterministic build. The new wallet code will be delivered that way too, in its own repo with its own fresh code files and dynamically linking to the crypto lib.

With deterministically built shared libraries, I'm thinking of signing the hash and hardcoding both hash and sig into the code base (i.e. have binaries hash and check the sig for the shared libs before loading them), but that's an egg and chicken problem with the crypto lib (you need the crypto methods to hash and check sigs) so I'm still wondering if that's possible/desirable.

One wallet <-> one backup.

There is no relation between 2 wallets, even if they were made within the same process. The root keys are just plain PRNG pulls. If you want to derive several wallets from the same root, you'll have to wait for BIP32 wallets.

It will need a rescan, don't have to go as far as rebuild. It is indeed missing some tx hashes.

I have a fix for that in 0.95

At some point but not in the next update. Doesn't matter for your particular case, the original tx would have to flag RBF to be replaceable anyways. You can always try a child pays for parent to hurry things up, some pools do prioritize those I believe.

You can look at the raw tx after signing it, in the offline signing/broadcasting dialog.

Looks like he chose to remove it.

hash the file (sha256sum), check it matches the hash in the signed hashes file for 0.92.3. Then check that signed hashes file is signed by Alan's offline signing key. If you're not willing to go down that route, you should build from scratch.


Doesn't matter what the GUI shows on both ends. If as an attacker I have access to what code runs on your signer, I could wipe your entire wallet after you've broadcasted a single tx signed with this malicious code, if I wasn't trying to be sneaky.

If I wanted to be stealthier, I'd still manage to reveal all private keys on your wallet after the one you signed with, with a single tx broadcasted to the network. An attacker with enough motivation would figure out which parts of the code base to alter to corrupt the signer in this way.

tldr: do not use binaries without signed hash, ideally build the code yourself, and best would be to review the code before using it (now that's going far I know)

Unless you verify the installer hash vs the signature files, you are taking massive risks.

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BitcoinArmory.sln

Open this file in MSVS, make sure the swigwin root folder is in the same folder as this file.

Also use this as a general reference:

https://github.com/goatpig/BitcoinArmory/blob/master/windowsbuild/Windows_build_notes.md

It's fairly easy with MSVS.

First off get MSVS 2015 express on your online machine, checkout the 0.92.3 tag on the repo and build the cpp project in x86. Once you have that covered, I'll walk you through the python part.

You would have to build it yourself. It's not as hard as it sounds.

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L114

Try with this. It looks like one call returns ZC outputs while the other doesn't and it gets confused there. Most likely a bug. I'll to have look into it at some point.

How many inputs do you have in the wallet? Are you trying to spend unconfirmed change? Did you create the ustx with enableZC = True?

You should

supernode? You using 0.93?