Either there is a zombie armorydb instance or there is another process listening on the port it is trying to use.

Armory is offline if it isn't allowing you to use SegWit address types. You need to post your logs to get help on that front.

Look up the stuxnet story for an example of attacking air gapped machines via a USB rootkit. Spoilers: it was pulled by a state actor, took untold resources and still required physical access to the laptop of one of the engineers working on the target system.


You can extract WO wallet backups. You'll get 4 lines instead of 2. You can recreate the WO on your online machine in this way, without having to rely on a flash drive.

This is typically when the progress bars are passed a value that is below 0 or above 100. Floating point rounding will do that near 100%.

As long as you verify the signature on the software you have downloaded (or built if from source, verifying the sig on the tag), you know your wallet software isn't compromised. Here we're assuming the developer is well established and trusted. This will be our premise for the practical attacks on air gapped signers. We're also assuming there isn't just someone able to point a camera at your screen/keyboard when you type in your password then walk in and steal the signer. We're only addressing software attacks.

At payment time, there are 3 attack angles:

1. Swap the payment and/or change address when constructing the unsigned transaction.

2. Read decrypted private keys at signature time and write them to the flash drive for extraction.

3. Corrupt the offline software to facilitate either of these 2 attacks (swap addresses at sign time instead of during creation).

At receive time, there is just one:

1. Swap the payment address with the attackers.


Defense against these practices are as follow:

a. Your signer should have a strong user and root password. The wallet's binary files should be set to [execute + read only]. This will prevent malware from modifying the code files.
b. Thanks to the previous step, you can have a strong expectation the code that is running is the one you verified. You can therefor trust the addresses it is rendering on screen.
c. You should always verify what addresses you are paying to and what change amount you are getting back before signing any transaction. You should also procure your payment addresses from the offline signer instead of the online machine (which may be compromised). These practices will thwart address swapping attacks

If you are paranoid about the flash drives you are using and USB rootkits, you need to take extra steps:
d. No amount of USB flashdrive corruption can steal coins until after you bring the flashdrive back from the offline signer.
e. In this case using a brand new flash drive per operations when taking data from the online machine to the offline machine prevents all possible leaks through the flash drive. Discard the flash drive, never reuse it. Formatting it is useless, rootkits persist that because they embed themselves in the USB drive's own controller, not the NVRAM.

f. Extract the signed transaction from your signer through other means. You can print out signed transactions in hex. Either write them down (~260 bytes tx will be ~520 characters), or use fancier stuff, specifically QR codes with a camera on the recipient device.
g. Used a 3rd device. The purpose of this device is to receive the signed transaction for inspection before moving to the online machine. This device must be air gapped as well. This device does not need to run Armory, but it can.
h. On the 3rd device, decode the transaction with some piece of software (a very simple offline html page can do that for you), and check the payment addresses.

Finally, take that signed transaction to an online machine (ideally not the one that generated the transaction, so potentially a 4th) and broadcast it.

Note that this is a super paranoid setup, but if you're worried about USB root kits, you have to understand that they are very difficult to deploy since they need to target the victims specific USB hardware (both online and offline machine) + the USB dongle, as well as the software stack used. Introducing new machines and adding hops where the USB dongle isn't involved, as well as cycling dongles, blocks what is an overly expensive and convoluted attack to pull off in the first place.

Honestly, you can boil down good security practices to the following few steps and sleep safe:
- check the sig on the software you download
- don't install garbage on your online machine, bitcoin related or otherwise, do not trust any wallet you had to pay for, only use open source software. If you can't help yourself, have a machine that's cleaner for your actual personal stuff (email, banking, WO wallet, etc...).
- use an offline signer
- keep some fractions of a coin in a hot wallet on your online machine, makes spending small sums painless and acts as a canary.
- check your payment and change addresses at signature time.
- grab payment addresses from your offline machine, not the online one.

Get rid of that space in the path. Start ArmoryDB manually with --satoshi-datadir=[/path/to/block/data], see if it starts syncing.

I don't think so, some people post theirs in their signature even.

What CPU are you using? I'm guessing it's old. Install the noasm version and try again. I suggest you avoid spaces in your paths too.

This happens when the installer tries to register the shortcuts in the start menu. I guess the call is either outdated for your version of gnome or you're not using gnome at all.

Where are you seeing this error?

I've reworked this code into the C++ side recently, I may be confusing the old functionality with the new one. He could get his wallet to restore by modifying the Python code to ignore checksum errors.

Turn off auto bitcoind in the File -> Settings menu.

Last 4 characters shouldn't affect the final ID. Maybe you are getting combinations that have a "repair" candidate. At any rate, you can only use characters from the narrow set.

This is the character set:

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

This is the checksum calculation:

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

The hash function is 2 passes of sha256

Out of curiosity, are there spaces at all in your paths?

The last 4 characters are checksums. The actual 16 bytes of data per line are encoded in the first 8 "words". You can write gibberish for the last 4 characters if you want. Armory will complain the checksums are invalid and will ask you to explicitly check the proposed wallet id with the one written on your backup. If the two match, you're all good.

Next version will run natively on OSX

Maybe none of this actually affects you. I just remembered the arg list passed to CppBridge has --testnet hardcoded in there. You need to run ArmoryDB with --testnet too.

How many addresses are in your wallet? Consider deleting the Armory /databases folder and letting rebuild. Should take 15~60min.

satoshi-datadir in ArmoryQt/CppBrdige does not currently have an effect. This an argument that only ArmoryDB uses. You are spawning ArmoryDB manually.


Sorry about the delay. I was gonna tell you to give me the log files but then I realized CppBridge overwrites ArmoryDB's log file, so I went about fixing that and... got into a giant refactoring. Pulled a string, unraveled the whole sweater kinda thing. I'll let you know when I push the new code, couple days from now I expect. Then you'll be able to run CppBridge again and feed me the logs for troubleshooting.

If you're willing to write it, I'll sticky and lock the thread. Thanks for the help at any rate.