Moving away from both py2 and qt4. The dev branch as you've found out runs on py3. I have not migrated to qt5 yet, that will come soon.


A quick history on the architectural changes:

- Prior to 0.94, all of Armory C++ code was made available as a shared library to Python, using SWIG.

- The next step was to isolate the blockchain service (ArmoryDB) from the rest of the wallet. The client (ArmoryQt/Python) talked to the blockchain server (ArmoryDB/C++) over a socket, using the FCGI protocol (some older protocol from the CGI days, meant to sit behind a HTTP daemon). This connection was not encrypted. ArmoryQt would spawn the DB on its own, connect to it locally and do its thing. Connecting the client to a remote ArmoryDB was not recommended, due to the lack of encryption. Savvy users would typically go around that limitation by SSH'ing into their remote system.

- The current iteration (in the dev branch) uses WebSockets (via LWS). LWS is a robust lib that can handle exposure to the WAN. It can also be paired with a load balancing front (nginx is easy to setup for one) and/or operated behind a cloud host (cloudflare/linode and the likes). The connection has its own AEAD layer added (chacha20poly1305). You can enable TLS in LWS at your own discretion but it isn't on by default and will require setting a few flags in the code and rebuilding ArmoryDB. Since the connection between client and server is now encrypted and authenticated, you need to share keys between the 2 before a connection can be successfully established. This is where your setup is failing atm. More on this at the end.

- SWIG has also been dropped. It didn't mesh well with py3 and imposed annoying restrictions on the build system (particularly with OSX). I didn't find a satisfactory replacement for SWIG so I ended up writing what amounts to a RPC API (CppBridge). This new process talks to ArmoryDB as well as handles wallets and all the crypto. The Python client has been relegated to a dumb interface: all it does is render GUI, the heavy lifting is done in CppBridge. CppBridge will also automate ArmoryDB (this isn't implemented yet).

- CppBridge talks to ArmoryQt through a socket as well. This socket is not yet encrypted, I am currently working on this. There is no fitting chacha20poly1305 Python package out there so I am in the process of creating one myself using CFFI. This connection will be authenticated as well, so it will too require a key share. ArmoryQt automates CppBridge.

-----------------------------------------

Regarding key shares, the default mode for the AEAD channels is 2-way (client authenticates server, server authenticates client). There is a 1-way mode as well (client authenticates server, server does not authenticate client). This mode is only available for ArmoryDB. It needs to be started with --public, and so does the client (1-way clients can't speak to 2-way servers, 2-way clients can't speak to 1-way servers).

In your specific case, to get the dev branch running you would have to share the ArmoryDB's key with CppBridge and vice versa. Assuming you use a 1-way setup, only CppBridge (the client) needs to know of ArmoryDB's key (the server). The keys are stored in dedicated key stores. CppBridge looks for its keys in clients.peers. ArmoryDB looks for them in server.peers. Both these files (when used) are found in your datadir (~/.armory). Ephemeral setups ignore these files. These are used for on the fly key shares when one process automates the other. Since you are running ArmoryDB manually (no other way to do this atm), you are using static keys, hence the key stores.

You can view the content of keys stores and manipulate them with the help of a plain command line tool found in /cppForSwig/KeyManager. I have yet to write any documentation for this tool, but the code file is small and fairly easy to parse: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/KeyManager.cpp

Currently, CppBridge is hardcoded to accept any server key in a 1-way setup. This means you do not need to actually setup a manual key share, but instead you would need to run both CppBridge and ArmoryDB with --public. ArmoryQt should already pass it this argument to CppBridge, so chances are you are missing --public when running ArmoryDB. In the future I'll remove this shortcut. By then CppBridge will have the code to automate ArmoryDB and will setup an ephemeral key share to secure the socket. It will do the same with the socket to ArmoryQt. The key share process will be for people looking to access a DB remotely and/or allow access to select known peers (or open it up to the public).

Ubuntu, anything 19 or prior, will let you setup Armory easily. You can setup a VM on your main system if you don't want to use another PC.

Pruned node? Armory can't work against a pruned node. Are you sure you have the 300GB on disk?

How many files are in this folder: C:\Users\powpig\AppData\Roaming/Bitcoin/blocks

How large are the first files? Also, check read permissions on that folder.

Is there a zombie instance of ArmoryDB.exe running? Kill that if so. From the cmd prompt, browse to the Armory binary folder (Armory in Program Files) and run ArmoryDB.exe. What do you get?

It's failing to read the data in that folder. Is this where your blockchain data is? Does your user account have permission to read this folder?

It's trying to automate the bitcoin process but can't find it. I'm guessing the binary is on your external drive too. I suggest you start Bitcoin-Qt manually and just let it run, then start Armory and report here.

Start Armory, grab log files from the Files -> Export logs menu. This just a text file, open it and copy paste the content in pastebin.org. This will generate a link, post it here.

It looks like your node is resyncing from scratch.


DB is looking for the block files here:


Is this correct? At any rate, start Bitcoin-Qt manually and let it fully sync. Then delete the content of your armory db folder (C:\Users\powpig\AppData\Roaming\Armory\databases). With Bitcoin-Qt still running, start Armory and report here.

Why trust when you can verify?


Half of these aren't even wallets, they're custodians. The client side is just a dumb interface talking over a web API. Bitcoin Wallet and Mycelium are actual mobile wallets, both open source.

Currently I'm working on the py3 migration. The dev branch only runs on py3 now, but that has introduced a bunch of regressions. I have to fix those before moving on to the Qt5 migration. At a glance, that part is fairly straight forward though. Most of the migration work is an opportunity to move a bunch of sensitive code (wallet crypto and the like) to C++ API. This separates the mission critical code from Python and the meshed in Qt stuff, and gives me better flexibility for test coverage.

I'm currently moving all the wallet backup code over. That's the last major piece of code that needs reworked into the API before I can look at the Qt5 migration and pushing out some test builds.

I work in the dev branch:

https://github.com/goatpig/BitcoinArmory/tree/dev

Since the tx went through the RPC, Core can correctly assume this tx is yours. I don't know why it would keep track of it, and somehow I doubt zapwallettxes has an actual effect in this case. I'm going to guess Achow only suggested to use this CLI arg as part of a the standard procedure to clean up stuck transactions in Core's Wallet. Armory isn't related to Core's wallet, it only makes use of the networking and consensus parts.

You can simply delete mempool.dat in the bitcoin datadir.

Disable auto bitcoind. Start Core manually, let it sync, then start Armory.

Port 9001 is most likely busy.

Owned by the former maintainers. I use my repo (goatpig/BitcoinArmory on github). It has a gh-pages branch for btcarmory.com in there. You can look at development in the dev branch. Master only receives signed tags for releases.

Reindexing is done on the entire chain unless you explicitly tell your node to assume the chain is valid up to a certain height (-assumevalid=XXXXX is the arg I believe). Deleting only up to the bad data instead of the whole thing reduces how you have to download again. Block download speed can be a bottleneck.

There is no such thing as "conversion", you have to spend the coins from one script type to another.

If you are going to reindex Core, you should delete the last few blkXXXXX.dat files. The error you are getting from Armory means that it is failing to match a block's list of transaction with its header (what carries the proof of work). Armory is most likely stuck at that specific block height because it rejects the next block (the one with the merkle error) and therefor fails to extend the chain.

Core checks blocks then writes them to disk. It doesn't check that the data written to disk matches what it has checked, therefor write errors go through transparently and Armory runs into them later. A reindex tells Core to recheck all blockchain data, which I believe leads to redownloading bad data (don't quote me on that). Reindexing is pretty expensive, so I'd suggest you just nuke the last few block files and restart Core. That will trigger a reindexing on its own and also make sure you're not carrying the botched block anymore.