In Files -> Settings, turn off auto bitcoind (should be the first checkbox). Then try again and report here.

Try the following: create a shortcut for ArmoryQt.exe and add your arguments at the end of the target field (prefixed with --).

HWI is in Python, Core is in C++. I don't see them bothering with this kind of a headache.

There is a PSBT implementation in the dev branch. It's about 95% compliant (doesn't really deal with custom fields yet).

These are ARM chips afaik, so it would definitely break the x86 breaks.

This is where Armory is looking for your block data. According to your second post, this folder does not exist. According to your first post, you downloaded the blockchain over the course of 6-7 days. Armory needs access to that data, you need to tell it where to find it if it's not in the default location. It can't just guess that for you.


I've asked you for the location of your block data 3 times now, and I still haven't got an answer. Put yourself in my shoes.

Where is your blockchain data? Did you set a custom folder? Armory cannot find your block data in the default location. Without that, it cannot operate.

There is no other version, you've got the right one.


Then according to your screenshot, dbLog.txt should be in C:\Users\Martin\AppData\Roaming\Armory. Can you list the files in that folder?

Armory is beta software.


It's not looking for block data in the default location, which you said is not right. Where did you download the blockchain?


Does your user/Armory have permission to write in C:\Users\Martin\AppData\Roaming?

It would be one element to consider in a set of variables while researching the topic. Don't get me wrong though, if I was to invest time reviewing 3rd party hosts, the main criteria would be DevOps.


Google is deeply intertwined with the US federal government. That gives them great privilege, but it also gives the US plenty of leverage on them. A better example of the type of relationship that exists between the regulator and the populace would be the prohibition era, the war on drugs, silk road and and the likes. Government can easily clamp down on regulated markets. It has a long history of utter failure when it comes to shoving those regulations down the throat of private individuals.

Not only would it be hard for them to intervene in the development of FOSS of the participative/non profit kind; even if they managed to force code in there, they wouldn't be able to force the populace to run it. With that in mind, I do agree that it's better to be ahead of the curve on these matters. I simply find this particular one a lesser threat.

This is the line you get once the DB is ready. It can only enable ZC tracking after the initial setup. What's the top block in there? Again, posting logs/command line outputs would speed this up a lot.


Should be in the same folder as the .conf

I don't mind mirroring the repo on Gitlab, but I can't do that trivially. I'd have to research the topic properly first.


Regulate development of a free open source wallet with no profit model and not even donations? Good luck with that.

The primary vector for government regulation is businesses, which is a primary proxy to one's pocket. There is neither a business nor a pocket involved here. What are they gonna do, throw me in jail cause I won't produce the emails and BTC balance of Armory users? There is no registration scheme nor phone home code in Armory. I don't put out supernodes for people to query blockchain data from, you have to run your own Core node to user Armory. This information simply does not exist in a centralized fashion, anywhere. There isn't even a door for them to get their foot through.

And don't think this is just a speculative scenario on my part. I know first hand of other wallet developers that have received summons from the government to out their users. There is simply no information to be had with Armory, no license to revoke, no red tape to throw at me.

I guess they could put a gun to my head and force me to add code in there to track the users, but nobody has to run that code (nor do I expect they will).

I would indeed need to see the whole log in order to help with offline issue. For now it looks like you're trying to use a custom Core path. You need to try and start ArmoryDB manually (from the command line), but first set your custom path using the db config file:

A lot of the ATI code has been replaced, albeit not all of it. 100% of the wallet and signer code is my work, ~95% of the DB/server code as well. ATI code is mostly in the GUI at this point (the python codebase). Some of the commonly used helper code on the C++ side is ATI. I do plan on eventually replacing everything.

About to go to bed, I'll go through this thread tomorrow and try to help.

This is outdated advice, and bitcoinarmory.com doesn't even carry my latest releases. Set server=1 in your bitcoin.conf, it will do wonders.

That's on the of the purposes of the RPC interface, node statistics. The only other available connection to a Core node is through the P2P, and for various reasons you cannot guess the current top from that connection.


You're better of itemizing the steps instead of letting Armory automate everything, for sure.

Have you setup Core's RPC interface? When Armory has access to the RPC, it will know that Core is updating the chain and wait before catching up. If it doesn't however, that's a good way to slow things down as Armory will contest Core for CPU and I/O resources while catching up via the small batches of blocks Core writes to disk, often even going back over the same batch several times as some data may be missing (Core's commit to disk is async and out of order).

New code has full bip32 and bech32 support. Most of what's left is migrating stuff around from qt4 to qt5, but Ive been held up by other stuff at my day job. I am motivated to push this thing out the door so that I can start on taproot integration however, which is expected in October (IIRC). I got my work cut out for me.

Armory does not use BIP39 backups, please don't confuse users.


You need to elaborate a little on this. Consider posting your log files as well, in case there's an obvious error in there.