I don't think that's necessary. The data is somewhere on your system, just need to find it. Hell, you could look at folder sizes and figure it out that way. Some 400GB of data doesn't just sneak around on a disk.

You have to cd to the folder where the binary is installed first. I honestly don't remember where it goes on Ubuntu. I'm guessing /usr/local/bin or /usr/local/lib/Armory. Try "whereis ArmoryDB" or cd to /usr and "find . ArmoryDB".


When you start BitcoinQt, what does it show you? I believe it can display where the blockchain data is located. Do you have a ./bitcoin folder in your home folder? You need to find where Core downloaded the blockchain data and feed that to Armory. If you find it and Armory can't read it, then it's a permission issue. We can look at that too.

It cannot find bitcoind, turn off auto bitcoin management in Armory (first page in File -> Settings) and run bitcoind manually. Probably this is because you installed bitcoin via snap


This looks wrong. Your blockchain data should be in ~/.bitcoin. This is the folder path you should give it. Try the following:

- From the terminal, cd to the Armory install folder: /usr/local/lib/armory
- Run the db process on its own like this: ./ArmoryDB --satoshi-datadir=/home/*USERNAME*/.bitcoin
- If it starts building the database, let it go all the way. Once it's done, start ArmoryQt.

Unfortunately Armory cannot run against pruned nodes at the moment.

It cannot find your blockchain data. Are you using a custom Core folder? Is it running in pruned mode?

Did you write your root key down? The software is failing to produce the expected checksum from your input, and the error is big enough that it can't autocorrect, suggesting at least 2 characters are wrong.

1. How much free disk space do you have on the drive with the blockchain data?
2. Can you start bitcoind/qt on its own? What's your top block? Is your Core instance in sync with the network?
3. After starting bitcoind/qt on its own, assuming it's in sync, start ArmoryDB by itself from the command line and post the output here (go through pastebin for big splashes of text)

If you're looking to put money into this, you should consider a CUDA implementations and either buying a RTX card or renting a few hours worth of an A100. You first need to estimate the amount of attempts you need to crack the password (known characters vs unknown characters, dictionnary size, that kinda stuff). Based on that you can project a budget and decide if you need a CPU or GPU approach.

Modern graphic & compute cards have plenty of RAM available. They can also make use of system RAM seamlessly (though at latency cost). Still, they're valid candidates for memory heavy KDFs, unlike 10 years ago. I don't know what the CUDA core to sha2 thread ratio looks like, but a rtx3080 has enough ram to handle ~400 32MB Scrypt instances.

You would need a CUDA implementation of Scrypt, which I suspect the Litecoin community knows a thing or two about.

You are looking at 2 different things here:

- Blockchain size:

You have to have a copy of the Bitcoin blockchain. This is a design choice for Armory, it's a full wallet.

- Qt4:

That, along with py2, have been deprecated a long time ago, no modern OS support this stuff anymore. In the dev branch, there's a version that runs on py3/qt5 but it's not very user friendly. Assuming you do not want to download chain, you have 2 approaches to accessing your funds:

1. export the private keys to Electrum

2. build the dev branch from source. I'll then provide you with a remote supernode from which you can query your balance data. That will allow you to create transactions to move your funds out. This is a more involved process than the first option and will require more effort on your end than the first option. I'll try to handhold you along the way however. Up to you.

It's an in house implementation of Scrypt. I believe that's what Litecoin uses for their block hashing, maybe you could look there for some breakthrough in implemetation?


The allocation is done via the default STL container under the hood (underlying container is std::vector<uint8_t>). Not much for you to do here, lookup table is preallocated:


You shouldn't do this from Python. It accesses the C++ code through the SWIG wrapper, this leads to multiple unnecessary allocations and copies. Also you're taking the hit for the Python runtime, and Python has no effective multi tasking, you'd have to multiprocess. That too isn't all that good, context switching for processes is significantly more expensive than for threads.

If you want to squeeze the most of your hardware on this task you'd need the following:
- Use an optimized, SSE/AVX enabled implementation of sha2-512. Armory 0.96.5 uses an old CryptoPP implementation from circa 2012, there could to be faster stuff out there by now. Building it with a modern compiler could help too.
- Use the C++ code, do NOT go through Python, multithread it in C++
- Run it in on some barethread Linux distro, not Windows. Do not mount a swap file either.
- Profile the CPU load to figure out the optimal thread count. Try with hyperthreading/SMT on & off. Try pining threads to explicit cores.

There's a weird tx in testnet that breaks the DB scanner. I have fixed this in the dev branch, but that code is for along compared to 0.96.5 that I can't just ship the fix back into it.

Says the file is cancelled. Try copying the last few thousand lines in pastebin and post the link here.

Armory is trying to connect to your node over port 8333. Is this port used by another process? Or maybe you have an antivirus blocking it? Look for the bitcoin core logs and post that here. You should find it in ~\AppData\Roaming\Bitcoin\debug.log

It can't connect to bitcoind/qt. Did you start your bitcoin core client?

That's an artifact of Windows compilation. What you are seeing is the path where the source resided on my computer at the time of building the Windows binary. This is the underlying code here:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/log.h#L70

For some reason on Windows it resolves __FILE__ to the full path instead of relative path. Go figure. I haven't gotten around to that, and I will probably replace the current log code with spdlog anyways.

There is compounding confusion in this log system, because the first half of the log is generated by the Python code and the dynamically loaded C++ code from SWIG library. That stuff runs on relative paths, for whatever reason. The second half is the concatenation of ArmoryDB's log, which has the full path resolution. Chaos ensues. You'll also notice the logs summoned from the Python side renders time as timestamps, where as the C++ logs renders them as datetime. Gotta clean up that mess at some point.

Where do you see that he changed his paths? I dont.


Please, follow my instructions here and report back.

There isn't much to go on in the logs. It seems to be having trouble starting bitcoind.

Start bitcoin-qt manually, let it progress, also check your free disk space. If it all looks good, start ArmoryDB manually, then start ArmoryQt. You are using default paths so that should work.

Apple has this habit of pushing compatibility breaking major updates. Likely to get the SWIG library to work, you'd need to build it with a recent version of XCode. Even if you managed to do that, you need to get through the py2/qt4 hurdle.

If you really want Armory to work on OSX, you're better off trying to build from the dev branch, which drops SWIG and runs on py3/qt5.

It's failing to load the C++ library that Python needs to access. You're better off trying to run it in a VM if all you got access to is OSX.

1. Did your chain data get pruned after you installed 25.0?
2. How many blocks is Core showing?
3. How much disk space do you have left?