Your issue is that Armory is failing to auto detect your Bitcoin folder. You need to enforce it manually through the --satoshi-datadir command line argument.

No changes since the last testing release (0.94.99.1). I've decided to sticky the latest stable release thread from now. Enjoy

Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.0

Changelog:

https://github.com/goatpig/BitcoinArmory/blob/v0.95.0/changelog.txt

- Forgot to bump the version and add the date in the changelog, will do for 0.95.1
- On windows, the automated DB will spawn a command line dialog. This wasn't the intention originally, but it goes a long way conveying the change in architecture. I've decided to leave it as is until 0.95.1.

*************************************

Botched auto bitcoind management on Windows,
you'll have to turn it off until I get a fix out.

**************************************

You are confusing the paper backup dialog with the password prompt. They are not the same thing.

The first thing you need to do is to describe in as many details as possible how you go from "I have a password" to this error message.


Next, answer this. "The latest version" is not a valid reply.

If you have some python in you, there is a hinted brute force script here: https://github.com/goatpig/BitcoinArmory/blob/master/extras/findpass.py

It can't even read bitcoin.conf. Does the file exist?

The new wallets are complicated because of the amount of new stuff I want to cram in there. Just delivering BIP32 support is the matter of a day. But adding the features incrementally results in a constantly changing wallet format. I want it to be done once and for all so that makes things a bit more complicated.

Best practice is to get Armory online first, then provide addresses to receive funds. Otherwise you will find yourself in a situation where you have funds in your wallet but are possibly several days away from being able spend them because you are missing some 100GB worth of data.

1) is the only consistent solution, since backups won't convey the extra flag and legacy wallets can't carry compressed keys without significant changes.

2) is the intersection between the path of least resistance and lowest runtime resource requirement. Requires 1) as a backdrop for restored wallets.

3) is more expensive to implement than 2) but is immune to unforeseen snafus with unused fields. This is basically how lockboxes are implemented. The independent container can also be carried around with an optional expert feature to blanket compress all keys in case of a blind restore.

Ideally I don't want the old wallets to have any SW capacity. SW requires deep modifications to the signer and wallet format. My original plan was to force people to upgrade to the new wallet format if they want SW support and allow legacy branches to exists within the new wallets, i.e. importing your root key to the new wallet format would result in one Armory 1.35 derivation branch and any amount of BIP32 branches.

The issue with this new restriction on SW inputs is that now I either have to rush the new wallets out or extend the legacy wallet format. Or not offer SW at activation, which I'd rather avoid.

Addresses for compressed pubkeys differ from their uncompressed counterparts (the raw data is different thus the hash digest is different). The database tracks addresses by their hash160 value (the common representation in transaction outputs and what Armory uses to create recipient scripts).

For the DB to track addresses based on compressed pub keys, it needs the hashes for the compressed keys. The DB does not deal in public keys, only the client does. This means the client has to deliver hashes for compressed public keys.

---------

So far so good, complications start here:

I don't want to modify the existing wallet format for 2 reasons:

1) It's an age old code (in the Bitcoin sense) that has proven it's robustness. If it's not broken, I'm not gonna fix it.

2) Some people may want to stay away from SegWit for whatever reasons, one being they don't trust me to handle crypto related code (again, for whatever reasons).

In light of these reasons, I do not want to modify the existing wallet code. As a matter of fact, the current wallets are mostly implemented in Python, whereas the signer code I'm writing for SegWit and subsequent wallet format that will fully leverage that signer will be in C++. This will further the separation of these 2 mission critical sources. The new signer will be proxied into the existing wallet pipeline only for SW signing.

The legacy wallet code and signer will remain in Armory, and the new wallets and signer will coexist with it during a long phase where the new code will eventually be enabled by default. At first it will only operate when signing SW transactions, which the legacy signer is incapable of.

---------

To get back on topic, I do not want to modify the legacy wallet code to save compressed pubkey hashes. I am left with:

1) Either compute all compressed keys on the fly at each start. This is slow. Refer to the wallet consistency check progress bar to get an idea of how long it would take to compute all the compressed keys for all your wallets.

2) Flag the addresses that have been used for SegWit operations through unused fields in the address container format.

3) Design a companion file to hold the meta data.

4) Some other exotic solution.

https://github.com/goatpig/BitcoinArmory/blob/testing/cppForSwig/BlockUtils.cpp#L714


Wait what? Sounds delicious!

Wireshark the data over the local socket, most likely the client is spamming the long poll callback request to the server.

Under ATI, this was in the tubes to synchronize several instances of Armory across machines.

I won't be doing this because

1) It acts as phone home code, and there won't be any of that under my watch.

2) This is over engineered if the only thing you want is to back up your wallets meta data. I plan to add a feature to extract meta data with the new wallets

3) If there is demand for this, I would consider adding a feature to the DB to distribute WO wallets and/or meta data to authenticated instances. This would keep all data under your control, but add remote sync'ing for deployment convenience.

4) I don't intent to monetize any feature in the main Armory client.

1) You should avoid auto bitcoind management while you still have a setup issue
2) Need armorycpplog.txt

Your wallet will always track 100 addresses ahead of the last used address as the lookup.

The simplest path forward is to sync Armory. Otherwise, pro actively extend your address chain and sweep the look up as well.

Let's see a log file. Also try 0.95:

https://github.com/goatpig/BitcoinArmory/releases

Don't put your datadir in a the program files folder, your user account most likely does not have the permission to write in that folder by default. Move your data to somewhere in the /Users folder.

In the ATI era, Armory would probe google.com to test for connectivity, as well as run some phone home code. A tor switch was introduced to disable that traffic.

Since 0.94, there is no more phone home code in Armory. By default, it only tries to connect to a Bitcoin node over a local socket. The tor encapsulation/proxying needs only happen at the node layer in this scenario.

Careful of hotlinks within Armory though, these will spawn your default browser which will connect over the open WAN if not setup to run through Tor.

Clearly there are 3 copies of that wallet file in your datadir, and Armory is prioritizing one of them.

The FCGI layer ip:port are hardcoded. You would have to set them to your desired value in your own builds if you want to stick to that interface.