0.96.5 uses the FCGI protocol, think PHP but persistent. In PHP, each request to the HTTP deamon (nginx in your case) spawn a dedicated PHP process that handles the request. In the persistent approach, the process is spawned once and the daemon routes the traffic to it. This how ArmoryDB works in that version (stuff in dev branch uses WS instead, much better).

The CGI model is for REST like designs: client sends a request, server replies. There is no built in feature for push (server pushing unsolicited data to clients), so the way notifications are done is through what's called long polling. The client sends a long lived request to the server, which will reply when it has data to push, and that request will be cycled once in a while (once a minute with ArmoryDB).

The registration message you see is for the long poll request. It signals that the server has seen a client and started the long polling cycle.

What is failing in your setup seems to be the individual requests. My guess is that it's asking for packets that are too big for nginx to let them through? Either your wallets grew enough that the ledger dump at startup exceeds nginx's packet size limit, or maybe some default nginx setting got updated along the way? You said you tried with a fresh db and no wallets loaded so if the issue is indeed packet size, I'd check for those defaults.

I've come to this conclusion because traffic works via SSH and not nginx, but at the same time the long poll lives through nginx until the client crashes (longpoll traffic is very light, we talking 100~200 bytes per instance). Client crash could be explained by receiving a mangled packet as well.

You could try to verify my assumption by fidgeting with nginx's settings? This mostly to satisfy your curiosity, I think SSH is better for your use case.

This means ArmoryQt is failing to connect to nginx. It's hard to know what's the cause right now. I would try connecting an ArmoryQt instance locally on that machine, or via a SSH tunnel/VPN (anything to bypass nginx, so as to confirm it as the culprit or rule it out).

Also check RAM usage and CPU load on the core/db machine, both idle and while connecting ArmoryQt.

There are some weird characters in your user name most likely (or at least in the path to AppData/Roaming/Armory). You need to use custom pathing to run Armory and Core from an ascii compliant location.

Sounds like an old version, try to update to 0.96.5: https://github.com/goatpig/BitcoinArmory/releases

1. Loading up the code
1.a. Start MSVC
1.b. Pick load solution and look for BitcoinArmory.sln in the cppForSwig folder
1.c. It will tell you it failed to load some projects, ignore the error
1.d. It will ask to convert the project, say yes to everything

2. Building ArmoryDB_debug.exe


2.a. Pick Debug and x64 (step 1. in the first screenshot)
2.b. Build the projects: from the Solution Explorer, right click on the relevant project then pick Build (first option in right click menu). Follow the order shown in the picture (LMBD_Win -> cryptopp -> BlockDataManager. Steps 2, 3, 4 in first screenshot). Only build these projects, ignore the others.

3. Setting your command line arguments


3.a. Right click the BlockDataManager project in the solution explorer, pick Properties (at the very bottom of the right click menu)
3.b. Set Configuration to Debug, Platform to x64 (steps 1&2 in second screenshot)
3.c. Pick Debugging in Configuration Properties list (step 3 in second screenshot)
3.d. Set your command line arguments (everything that comes after ArmoryDB.exe) in the Command Arguments field (step 4 in the second screenshot)

4. Running ArmoryDB_debug.exe


4.a. Right click the BlockDataManager project, pick Debug -> Start New Instance
4.b. This will start the ArmoryDB in debug, run through the steps (expect it to take ~20min rather than 1min). Once it fails, the debugger should catch the error and display callstack. Take a screenshot of MSVC when that happens and let me look at it.

You can go ahead, download and install MSVC community (https://visualstudio.microsoft.com/vs/features/cplusplus/). You only need the C++ compiler and features for our purposes, but if you want to play around with other languages, feel free. I'll try to build it in debug today and get back to you asap.

Ah sorry, the tag is "v0.96.5"

To get to debug armory, you will have to build a debug version of armorydb from source. It may sound scary but it's not that bad. There are 3 distinct steps:

Git:

1. Download and install "git for windows", use the defaults (https://gitforwindows.org)
2. Create a folder somewhere, in your Documents folder maybe, or use the default one git gives you. This is where git will download repos for you.
3. Start git bash (search for it from your start menu). Once in git bash:
   3.a. navigate to the folder you created
   3.b. type in the following commands:


At this point you have the source and it's ready to build. In the next post ill go through the steps to setup MSVC. It will take me a bit longer, have to redo the steps myself to make sure they're right.

It shows you that the coins are in your address up to the block height you've downloaded. You want to know if you have these coins *now*, you need the highest block *now*.

And that's with the empty wallet? And Core runs fine? I have no idea what's going on there, only solution I can think of atm is to run ArmoryDB in a debugger to catch the crash in there. If you're willing to install MSVC on your system, I can guide you through it.

System looks stable, temps are in check, memory usage doesn't even have time to spike. This kind of blowup is usually symptomatic of a system issue. This is reinforced by the random nature of the crash: if it was a specific block breaking the scan, it would fail at the same place every time, and empty wallets wouldn't reproduce.

It's hard to tell what's going on tbh. How much disk scape is available on F? How big is the databases folder currently? Also try the scan phase by starting ArmoryDB with --thread-count=1

ArmoryDB keeps track of the addresses you present it, so further scanning with fresh wallet will not evict the address from your WO. That test isn't very informative as a result. Try the following:

1. Start ArmoryQt in offline mode, go to File -> Settings, in the first section, uncheck the auto bitcoind management option. You can turn this back on later, but for the purpose of this test, I need it off. Also make sure it only is loading an empty wallet. Do not load your WO for this test either.
2. Delete the content of your database folder (F:\Armory\DB)
3. Without Core running, start ArmoryDB from the command line (it's in  F:\Armory):


It should start building the db. I'll need you to use a hardware monitor and report on the max values for CPU load & temps, as well as RAM usage and SSD load & temps. Use something like OpenHardwareMonitor. Make sure to reset it max values between build & scan phases, I need values for both.

4. Once it's done building, you can start ArmoryQt (remember, Core cannot run so auto bitcoind should be off). ArmoryQt should detect the current instance of ArmoryDB and feed it the addresses from the fresh wallet.
5. Report on how far it went. Also copy the text coming out of the command line prompt, this will have extra data that doesn't make it into the log, possibly some verbose for the error. I don't need the ArmoryQt logs for this, just the command line output.

From the looks of it, you're using 0.96. If you're trying to send BTC, you should upgrade to 0.96.5, fixes the bugs you're running into: https://github.com/goatpig/BitcoinArmory/releases

If you're looking to spend BCH, you will have to go through a more convoluted process:

1. You want to try 0.96.2 as the target release.
2.a. Find dedicated BCH wallet software (I dont have recommendations, sorry), create a wallet with that, back it up, test the backup. Then grab a legacy BCH address from said wallet (starts with a '2').
2.b. Make a backup of your Armory wallet if you don't already have one. Test the backup to be safe.

The hard part (you do not run Core for the entirety of these steps)

3. you will need to setup a dedicated "environment" for your BCH signature process:
   a. Create a copy of your blockchain data, cull blkXXXXX.data files away to be around 450~500k blocks. Aim for 30GB, you can add files as you go. You do not need the revXXXXX.dat files.
   b. Run a 0.96.2 version of ArmoryDB against this copy of the chain. You can get a standalone (no install) binary through the win64.zip release.
   c. Make a copy of your wallet in a dedicated datadir and run ArmoryQt 0.96.2 against it while the target ArmoryDB instance is running. You will require some path magic for this to work unfortunately. A "solution" to avoid the path-fu is to do this on a second PC. When this is finally running, you will have ArmoryQt running, showing the top block to be in that 450~500k range.
   d. You can now create an unsigned transaction moving your BCH to the freshly made BCH address from Armory. To do this, check the "create unsigned" checkbox in the Send dialog. You will be served with a blob. You can choose to sign it. Pick the BCH signer and sign it. Once the blob is signed, choose to export it as "raw hex".
   e.With the raw hex blob, you can now broadcast your tx via any online BCH broadcast tool, at your own leisure.

This is the leanest setup I can think of, as you would have to run some old version of the BCH node to get to broadcast from Armory, which is probably impossible these days, due to various backwards incompatible changes on the BCH side.

4. Bonus round:
   If you're paranoid, you can choose to create the signed BCH tx, then move your actual BTC to a new wallet via regular Armory, then broadcast the BCH tx last. At any rate, my recommendation is to move your BTC off that wallet if you're gonna split the BCH out.

Can you describe how you got to that error?

Did you move these coins since the BCH fork? Depending on that, the solution will differ a bit.

glad to hear

It complains that it cannot find older blkXXXXX.dat files, in this case blk02641.dat. Can you confirm that file is in your blockchain data folder? Im going to assume it is for the remainder of this post.


This setting is too approximative, the main way to clamp memory usage in ArmoryDB is by reducing thread count (--thread-count=X).

I don't know how memory is managed between containers and host. I've ran into the oomkiller a few times when running beefy containers + using a bunch of memory on the host (im on arch) and while the system recovers, a lot of processes blow up unpredictably. I can't tell if you're running in this issue because of corrupted data or because of weirdness with resource load within containers.

My suspicion is that a parser thread dies mid scan and you're seeing the consequences of that (block files are grabbed as whole, this would explain one file failing to scan entirely). --ram-usage controls how many block files can be parsed concurrently. Bitcoin Core keeps block files within 128MB so that's a proxy for memory usage in ArmoryDB. --thread-count limits the amount of threads the scanner gets to use and is a better predictor of resource load.

This is what I suggest for now:

1. Try to rescan (not rebuild) your db. If it fails at a different block file, then you are running into a concurrency issue. Toy with --ram-usage and --thread-count, maybe it will pass.
2. If it fails at the same block file, delete your database folder and try again. Does it fail at the same block file again during the new scan? It's possible the concurrency issue hit during the build phase and you're seeing the symptoms at the scan phase
3. In general, this is old code I haven't looked at in a while. If this problem persist, I'd invite you to try out the new code in the dev branch, as that's stuff I can realistically debug and fix.

You're better off delete Armory's databases folder in this case (/root/.armory/databases)

I'd suggest you run as user instead of root too. You can add the following to your dockerfile:

Are you trying to dockerize it because you're on a Windows host or is there another reason? Depending on what you're trying to achieve, I can help you with the docker file or the setup as a whole. If you're armed with patience, you could help me make the dev branch user friendly (at least the build & launch steps). That stuff works (I've been using it for my own stuff for over a year now), I just cant get around to make it user friendly. At any rate, a few notes:

1. ArmoryDB tracks the addresses in your wallets. If it sees them once, it will know then until you wipe/rebuild the "databases" folder (what the --dbdir argument points at). Since your db knows your addresses (it wouldn't try to scan otherwise), you can run "ArmoryDB --rescan" on its own (without either ArmoryQt or Core running) to get better verbose.

2. Dockerizing ArmoryDB isn't really useful imo. This is a headless C++ process, it doesn't have any linkage with Qt nor any other GUI library, it's the easiest part of the puzzle to build & run on any host OS. It needs read access to blockchain data and ~10GB for itself persisted across runs, so you will have to mount part of your host file system in there in all likelihood. It also mmap's the blockchain data, I don't know how docker/containerd/k8s deals with that. On the other hand, it talks to ArmoryQt via a socket, so you can run ArmoryDB and Core on your host, and containerize the client.

3. Containerizing the client is your best return on investment, this is where all the exotic requirements come from. I would run as a user, setup a python venv and install the dependencies via pip off of a lightweight image. This could probably work on alpine. I expect the main hurdle is to expose something that looks like a X server to the image.

You can update Core but make sure to disable blockchain data pruning or it will erase historical block data from your disk, which Armory requires.


Hard to say without seeing the full log file. From what you're showing, looks like some db data is mangled. I suggest a rescan, not a rebuild (yet).