Your main road block is that Armory currently runs on python2 & pyqt4, and both py2 and Qt4 have been dropped from ubuntu starting version 20. You should read this thread for a decent work around:

https://bitcointalk.org/index.php?topic=5261375.0

Otherwise, the simplest path forward is to run Armory from within a Ubuntu 19 VM.

The cookie file is created by ArmoryDB on startup if spawned with --cookie. A local client that spawns the DB will use --cookie. The file contains a one time token (random number generated at DB spawn) that the client reads. That token has to be passed to use certain elevated commands, notably the shutdown sequence. Without that token, a client cannot shutdown the DB, and the DB will persist the client. Restarting the client will have it connect to the existing DB process.

The DB controls Core. Core generates a cookie file as well, that holds a token to authenticate the user for Core's JSON-RPC API. If ArmoryDB cannot access that cookie file, it can't connect to Core's RPC. This means it will fail to get some status reports from Core, and it won't be able to shut it down.

Shutdowns are all graceful, requested through commands. There may be some verbose left in the Python client suggesting otherwise, but these are left overs from the previous implementation (when the Python client handled Core). They don't do anything anymore.

You can set the command line args in their respective config files btw:

- armoryqt.conf for ArmoryQt
- armorydb.conf for ArmoryDB

One command per line, no -- prefix

For some reason, python is refusing to read the port as a string.

https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L1796

Forcing str() there may be of help.

ArmoryQt talks to ArmoryDB over a socket. ArmoryDB talks to Core over a socket and reads Core's blockchain files. ArmoryQt does not talk to Core directly, it gets its status reports from ArmoryDB.

When you start ArmoryQt it will:

1) Check there's a Bitcoin Core process running, if not, try to spawn it. You can disable this option in the GUI (File -> Settings).
2) Try to connect to ArmoryDB, If that failed, try to spawn ArmoryDB, then try to connect again.

In the setup I propose, you would:

1) Start Core and ArmoryDB manually on the host system.
2) Start ArmoryQt within a docker container.
3) Setup the docker container so that ArmoryQt can connect to port 9001 on the host machine.

A few relevant Armory settings:

a) You can set a custom ArmoryDB port (--armorydb-port=xxxx on the client side, --fcgi-port on the DB side)
b) If the ArmoryDB IP is not 127.0.0.1 (you can set custom IPs with --armorydb-ip), the client will try to speak HTTP instead of FCGI to the DB. This is because FCGI is a protocol wrapped in HTTP, and the client expects to speak a remote DB, and FCGI expects to sit behind an HTTP deamon. This step is foregone for local client to DB connections, for ease of use. In this case, you should spawn the client --force-fcgi as well, to avoid issues. Otherwise, you'd have to put the DB behind nginx and connect the client to nginx.

As an example assuming your host system is accessible as 10.0.0.40 within the docker container, and you want to connect over port 5000, you would spawn ArmoryDB host side with this command:


and the client within the docker container with this command:

Sounds like python/swig shenanigans. Try

That's an odd way of doing it (running all process within docker and share the files across the host). My suggestion was to run Core and ArmoryDB on the host system, ArmoryQt within docker/VM, and point it to the port ArmoryDB is listening to. Would fix your permission issue too.

There are a couple people contributing to some specific aspects. I did pay a guy for a few months when I could afford it. The core of the work I do on my own. Development has been lagging behind cause of my day job these past couple years, but I hope getting more time starting this year to go back to a more frequent release schedule. I don't intent on dropping maintenance ever, even if there are ups and lows in the development speed.

I dont want that, it's grand fathered in from etotheipi's era. A lot of code was implement in Python, not just the GUI. Wallets, transaction signing, part of the interfacing with Core. In the current development state (as seen in the dev branch), everything but the GUI was redone in C++. It's an incremental development state. In 2017, I had to add SegWit support so I rewrote the signing code in C++. For this release cycle I needed BIP32, PSBT and public data encryption, so the whole wallet structure was redone in C++.

If I could just take the PyQt5 GUI and convert it to native Qt5 cheaply, I would. Issue is the GUI is hardcoded Qt4 into a ~10k LoC file, and then another ~10k across a few other files. Therefor, I have to take one development cycle to first migrate to Py3/Qt5 before I can look at this stuff. The migration though gets rid of SWIG and interfaces the client with the DB in an agnostic fashion.

Once I have Qt5 in there, I need to deliver some GUI elements and rework some others. I'll take that opportunity to implement that stuff in QML instead. Over time, once the enough of the new GUI elements have replaced the old hardcoded stuff, I'll bite the bullet and convert the rest of the GUI to QML. Then I'll consider getting rid of Python entirely or not. I don't like Python in the first place, but some useful libs like HWI are in Python, and I was considering doing hardware wallet support through that on the cheap, so I'm not 100% sure I want to prune Python out entirely in the long run.


Client talks to DB over a socket (DB listens), as long as you allow that through the docker container, you could run the client within a docker instance. I would say it's more demanding to run the whole stack in docker  since the DB requires local disk access to the blockchain data, meaning you need to bundle Core with its data in there as well.

I wish it was that easy. Working on the migration to py3/Qt5 for the next release.


If you want to go the install route, you need to install Qt4 on your system from an archive repo then install pyqt4 for py2 from pip. If I was you, I'd setup Core and ArmoryDB on the main system then have an encrypted Ubuntu19 VM for ArmoryQt (which will have your wallets) and setup a tunnel between the VM and the host so that the client can open a socket to the DB.

Ubuntu 20 comes with py3 by default, not py2.

Failed to talk to Core RPC, useful but not crucial. Are you running Core with --server=1?

Try creating the wallet in offline mode.

There's too much stuff mixed up in the logs. Delete them, start Armory again and post armoryqt.txt along with dbLog.txt.

You'll find the logs here: C:\Users\Owner\AppData\Roaming\Armory\

Log shows client is failing to talk to the DB. You should first update to 0.96.5.

My 2 cents:

When a regulated body receives your coins, they have to run them through a chain scoring service, which in itself is another regulated activity whose endgame is to tie on-chain funds to IRL identities. This is as hard of an erosion of financial privacy as it gets.

Let's be clear though, there is no such thing as a right (either negative or positive) to financial privacy in the legacy (fiat) system. The primary interlocutor for a regulated service is, well, the regulator. Customers come last typically. This is grandfathered into any new fintech markets from the legacy system design, and there isn't a lot you can do about it.

Getting back to the score chain services, there is another side to this story: these guys use a set heuristics (fairly dumb ones if you ask me) to flag coins on chain. Their heuristics may improve with time but one that isn't going to change is that coins that come out of a regulated exchange are considered clean. This therefor an alley to "launder" your coins from the perspective of these services, and regulators in general: get them in and out of an exchange. I believe this is what OP is referring to, and to be clear, I do not recommend doing this at all.

If you suspect your coins need cleaning, either because they are tied to your identity or flagged for whatever reason, passing them through an exchange will not do you much good. There are better ways to achieve this without handing out your SSN and a rectal scan to Coinbase.

There is also no guarantee a custodial service will pool their customers coins. There is actually regulatory precedent against that in the US, where BitFinex was ordered to hold individual wallets per customers, which is the precursor to the whole mess with BitGo that led to that 300k something heist back in 2018 (I believe, don't quote me on the year). You're better off observing their on-chain activity to get an idea whether they pool coins or not. On that basis, I'm gonna go on a limb and assume BitMex does pool to an extent.

On the other side, in the EU, custodial operators are obligated to keep track of user funds (I don't know to what specific extend). You should expect any service that is available in the EU (regardless of where they are based and the other markets they serve) to homogenize their customer tracking with that of the most restrictive jurisdiction they operate in (in this case, the EU). So looking at services that you believe pool coins, you shouldn't expect them to serve as a suitable "mixer" on the sole basis they're not an exchange.

Indeed.

It's either running into jibberish or it's failing to find the next within one of the block files blk01974.dat

You can try to salvage that by:

1. Delete all blk and rev files past 1974

2. Start Bitcoin-Qt on its own, let it sync. It won't download nearly as much data but it will recheck the chain as there will be a state mismatch caused by the missing files.

3. Once Core is ready, delete the content of /home/bblboy54/.armory/databases and start ArmoryDB from the terminal. Report here.

And what is that error?

How's your free disk space like?