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.

1) Get rid of armorydb.conf. Create a file named armoryqt.conf instead, in the same folder. Put this in there:


2) Delete the current DB.

3) Make sure auto bitcoind management is turned off (unchecked first checkbox in File > Settings).

4) DO NOT START BITCOINQT/BITCOIND. Your PC is anemic, it probably can't withstand the RAM load of both your node and the DB bootstrap at the same time.

5) Delete your logs (armoryqt.txt armorydb.txt)

6) Start ArmoryQt. Let it sync. If it fails post your logs again.

7) Once this is all done, you can start node manually. Doesn't really matter if the DB is running or not, but the preferred procedure is to start the node manually first, let it sync, then start ArmoryQt.

The explanation is this: Any BTC you have moved post fork will put your BTC DB is a state that makes the coins inexistent on the BCH side. Any coins you did not move, you can use the BTC DB to create a tx for, that will be valid on the BCH chain.

Therefor, to guarantee you have BTC DB state, you'd have to rewind your blockchain data to the fork point and sync a new Armory DB against that copy of the chain. Otherwise, bite the bullet and sync a BCH node, then build an ArmoryDB against that.

That only really works if you have not moved any BTC post fork or rewind your chain back.

These are lines for the node, i.e. they go into bitcoin.conf.

Do you use an antivirus? If so, check the quarantine container.

That got me confused.


I understand your point but this is something you can investigate later, once you have a functional system. For now, since you are requesting assistance, you need to follow the instructions you are given, which allows for controlling the environment.


You have to cd to the folder containing ArmoryDB.exe to run it from the command line (or type in the full binary path). At any rate, delete dbLog.txt, setup your armorydb.conf and go run the DB from the command line.

He could try the brute force script for the wallet but I do not have the strength in me to walk him through it.

1) Use RC3

2) Use config files

3) You can't mix and match chains and DBs. Use a dedicated folder for each

4) What BCH node are you using? Armory is not compatible anymore with that stuff since they changed the address format and magic number.

No. Using the daemon means you know what you are doing. If you cant run "python armoryd.py" from the command line, stay away from this.


Yes.


Create a wallet on whatever machine that can run ArmoryQT, take the wallet file to headless machine.

Offline, this is expected, you have to use a set of cli args:

https://github.com/goatpig/BitcoinArmory/blob/testing/changelog.txt#L14

Online, it means you're using a non segwit compatible node, or that your node is outright offline.

It won't show you addresses that aren't used nor requested. You need to extend the address chain, request new addresses or sync the wallet.

This is python 2.7

No, you have to freeze the script yourself into an executable.

Addresses are derived deterministically. If this address comes from wallet "2esgHgP7M", it's in there.

Each attempt requires a flat amount of RAM. This drastically reduces how many attempts you can perform in parallel. That's kind of the point of a decent KDF.




As long as your source of entropy isn't shit (please don't just put words together)

It's base58.


Lol no. You think phones in the future will carry terabytes of RAM? The KDF is basically Scrypt, forget it.

You'd have to elaborate on  what you mean by "Restored". Did you restore this wallet from the private root? What makes you think you have imports in there?