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?

1) Send your BTC to a new wallet the old fashioned way.

2) Do whatever with the original wallets, which only carry the shitcoins now.

1) Did you give bitwhatever an address or a wallet?

2) If you gave them a wallet, detail the steps.

3) You say they showed you a transaction on a webpage. Link this if there's no login needed to see it.


Define "public wallet" and "access".