Depends how much of the stack you are restarting. If it's everything (node, db, client), it's gonna take a couple minutes. If you just shut down the client but left the db and node running, restarting the client will basically be instant.

Delete dbLog.txt, try again and post the file. Same with armorylog.txt.

That's for autobitcoind, i.e. if you let ArmoryQt automate bitcoind for you.

Next thing I would have gone to is the Windows firewall but it seems you beat at it. If anything compare the BitcoinQt and bitcoind firewall rules. Who knows if you can fully disable that thing, Win10 and all...

I guess the only real way for you to know what's going on is to look at the connection loop in BitcoinP2P.cpp in a debugger.

I don't think there are submodules in ABC's repo. At least there are none in Core, so ABC would have had to had to add submodules recently. It won't do anything to initialized submodules on a repo that has none, but I'd rather people know that this step has no effect. That aside, this is a acceptable procedure. Note that you can verify a tag without checking it out. It's actually preferable to first verify the signature on the tag then to check it out than otherwise.

Post dbLog.txt

The "bump fee" feature spawns the Send dialog with the exact same tx settings preloaded (utxos, change address, payment address). At this point you can do anything you normally do in the Send dialog. You can also use the RBF control feature (under the coin control feature) to pick replaceable UTXOs and effectively create a completely different tx if you wish so.

I don't really know what else to look at then. I do not experience this issue at all on Win10 and I don't use bitcoind. There has to be something at socketing level. Do you run BitcoinQt with or without the wallet? Mine is always with disablewallet=1

Chances are your CPU is too old, you're gonna have to build from source.

There are builds for old CPUs (gcc4.7). Offline bundles are a different thing. They're a build + the collection of necessary dependencies to run the software. You can get these dependencies from the relevant public repository and they will work with your CPU as long as you chose the right architecture.

Put another way, if you are missing dependencies, you can simply grab those on your own. I test the offline bundles against freshly installed VMs, so as far as I know, they are fully functional. If you are missing dependencies on your machine, might as well list them here so that I can get an idea what's missing.

Installing dependencies is a one time thing (as long as you don't reinstall the OS). Once you have an offline bundle installed and functional, you most likely won't need the offline bundle for the next version, just package. I make a point in not inflating the list of dependencies needlessly, so that part should remain true. Matter of fact, I've drastically reduced it since 0.93. In other words, you could install the 0.93 offline bundle, update Armory to 0.96.4 and most likely get away with it.

This will sound harsh, but you seem to be under the impression that people using tether have a modicum of sense in them.

1) Observe the DB without "listen=1". Is it eating a lot of RAM or maxing out 1 CPU core?

2) With the same setup, run the DB manually instead of letting the client spawn it.

That's the last line the DB puts out once it's done initializing. You saying clients can't connect past that point? Is there not a line saying the Node is ready? Does it just miss all new blocks past that point (which would be a pathing issue, not a socketing one).

You could theoretically build the BARE db on a Pi assuming you use the lowest ram-usage setting. That DB is small enough that you won't run into LMDB issues, but you also have to consider total process RAM, which could exceed the addressable memory as a whole.

On Windows I use BitcoinQt exclusively and I don't use listen=1. listen=1 is to allow your node to be discovered by others on the network, resulting in incoming connections. Armory connects as an incoming node so maybe listen=1 affects the default connections ceiling (8 connections max).

I recommend use addnode because Armory does not present itself as an archival node over the P2P interface, which leads me to believe a Core instance limited to the default 8 outgoing connections would choose to suppress the ArmoryDB connection in favor of a real network node. I've often noticed my db gets booted off of my node, even in testnet, without the use of addnode. Addnode invariably fixes this issue.

I'm highlighting this issue because your logs demonstrate your node getting booted and reconnecting when using BitcoinQt.


I have never experienced my node trying to loopback to itself. Whiltelist allows for the connection (even if the node score would have the DB booted otherwise). It does not reserve a slot for the DB over other valid nodes.

Consider using addnode=127.0.0.1 in your node .conf. If your node fills up its default incoming slots, it may just kick ArmoryDB out as it identifies itself as basically a useless node.

The issue isn't the amount of memory, it's addressable space. LMDB maps all on disk data into memory. If that value exceeds the process addressable memory, you will get a critical failure. On 32 bit systems, process addressable memory maxes out around 2~3GB. Therefor, any file LMDB uses that exceeds 2GB in size cannot be created nor used on a 32bit system. This is a long winded way to saying please don't try this.

If you insist on attempting this setup, you should do it the smart way: create a 32bit VM of some Debian flavored distro, the closest you can to the target Raspbian version. Give this VM a copy of the blockchain, then build the smallest existing Armory DB on that VM (db-type=DB_BARE). This will give you a ~200MB database. Then take this DB with the relevant copy of the chain your Pi and cross your fingers.

DB is tied to the ondisk blockchain. You can't move a DB around to a different copy of the chain. Also I don't think the meta entries for LMDB are even the same going from 64 to 32 bits. It's typically bound to the pointer size, which naturally differs between 64 and 32 bits.

Sorting is a PITA to implement in GUI so don't hold your breath for that one.

Typically you don't need to, as the same files as the previous install will be copied over, overwriting the previous install. But it's preferable to "make uninstall", as it guarantees the old files are removed, in case some of these files are not covered by the new install.