These 2 versions are basically incompatible if you are signing for anything but P2PKH.

I need more detail. What was the state of your offline instance when you restored? Was this particular wallet there?

EDIT: did you cycle the .lmdb mirror wallet file?

How did you restore this wallet?

Applies to both.

If you restore on top of an existing wallet, you get the option to recover the meta data from the existing one (comments, address chain length, imports). This is the most likely explanation. You can delete imports from a wallet, but you have to be in Expert User mode.

That's unrelated.


There was no significant node changes in 0.16, should be fine.

You are not pathing correctly. Read this: https://btcarmory.com/docs/pathing

No, this specifically means get rid of the databases folder because you cannot swap DB mode on existing databases.

Screenshots are useless. Post logs.


That only works if you delete the previous DB first.

I did not fail to broadcast. Read the message again, it says everything you need to know.

What address type did you use? Chances are you're gonna have to setup your DB properly. Post your dbLog.txt for now.

This is not an error...

Nothing. They are leftovers verbose pertaining to the database design back from 2011.


The DB is trying to resolve the longest chain.


You should wait.

Let it finish. Your CPU is slow enough that benign dashboard message ends up getting spammed.


Professional grade? 2014 Xeons sported 18 Cores with HT. That's high grade. Your CPU doesn't even have HT. High end desktop from 2008 was 4c/8t...

As for USB2. The current blockchain folder is 166GB. At the effective sequential read speed of USB2, it would take 2h20 just to COPY the chain. How long do you think it's gonna need to actually process that data?


The blockchain organization process takes a few seconds on a modern computer. The reason this process has no detailed progress report is because it is so fast on a typical machine. I don't know where you got this PC, but it just doesn't fit the bill. The primary bottlenecks for blockchain processing are:

1) I/O
2) CPU

Both of which you the have low end of, from 15years ago. I can't help you there, sorry.

You can backup the seed of course, but you're sending it over a socket and it's sitting in your online machine as well. That's an attack surface you should be trying to reduce, not the other way around.


You can run 1 DB and let your users have access to their wallet in GUIs each. The DB also has its own language over the socket, which goes over the FCGI protocol, ie from your end you can display balance and history with HTML/js straight from the DB if you'd like to go down that route. The RPC is fine too.


It does that but you need to elaborate on your requirements and opsec. How many addresses do you expect to use per employee? If it's only 1, just use lockboxes. Do you intent to give your employees signing privileges? If no, then only load watching only wallets in armoryd. It can create unsigned transactions that you can review and sign with an offline GUI/armoryd instance that has the full wallets loaded.

At any rate you are better off just letting armoryd run on watching only wallets and let people sign offline through the GUI, whether it's you or your employees. This model suggests you create the wallets offline and only import the public seed in armoryd.

So the question remains, do you actually need to create full wallets at all from the RPC? Chances are you don't, and shouldn't.

The error means you didn't complete that step. You want to copy the content of the armoryd repo into the Armory repo. Then, if Armory is built, you can run armoryd.

remove the ram-usage line, see if it works.

Something is off with your armoryqt.conf. Post its content verbatim


2 cores, USB2. Moses' mobile phone was more powerful than that stuff.

Ugh my bad, it's lockboxes you can create remotely, not wallets.


The issue with creating wallets dynamically is 2 fold: your servers will be carrying the private seed, and how do you back that up? It's not that it can't be done, but the opsec are poop. What you'd want instead is a wallet model where you have one master seed, and any amount of child wallets derived on the fly from that seed. That's for 0.97, which is a couple months away at the earliest.


What I can offer you in the short term is a method to import wallets from their seed (either public or private). You'd have to create the wallets in the GUI, deal with the backups and what not, then you can register that wallet with armoryd through the 72 character seed.


What do you want this for? I think you're confused about Armory's stack. This is how it works:

- The GUI, which deals will all things UX and wallets/crypto. The GUI connects to the DB over a socket. The DB can be remote but right now there is no encryption layer over that socket. That's for 0.97 too.

- The DB, that deals with all things blockchain. A GUI registers the addresses in its loaded wallets with the DB. The DB tracks these addresses and passes on balances and historical data back to clients. The DB requires a full node that's fully compatible with Core's P2P, RPC and on disk blockdata serialization. The DB needs disk access to the blockdata. There can be many clients per DB.

- armoryd uses the same socketing interface as the GUI, i.e. it can connect to a DB remotely. armoryd DOES NOT interface with GUIs, or other armoryd instances. It only presents a JSON-RPC interface to users. Registering a wallet through armoryd will NOT affect other GUIs nor armoryd instances. It's just another isolated client.

From your description, it feels like you are expecting things out of armoryd that it was never designed to do. You should lay out your logistics at least, so we can tell if your requirements can be met.