The whole censorship resistance angle of Bitcoin goes out the window when you're trusting a custodian, specifically a regulated one. Regulated entities answer to the state first and foremost. They will tell your government how much coins you have and give them the funds if they ask hard enough. A storage solution that doesn't even offer you the opportunity to defend against a governmental attacks is worthless.

On Linux, Armory tries to spawn bitcoind (as in just this command, with that specific name). If typing "bitcoind" in your terminal does not spawn Core, then you can either make sure it does, or run Core manually.


New block & mempool notifications are grabbed over the Bitcoin P2P protocol. Same with tx broadcasting. Armory spoofs itself as a node to your local Core instance to this avail. RPC is not mandatory and is used to monitor the progress of the blockchain download (when Core is catching up on history) and as a fallback broadcast vector. This is because while RPC needs to be setup (it's an authenticated connection), whereas your node's P2P layer allows anyone in and is always on.

ArmoryDB does not need to talk to your Core node to read the blockchain data on disk. This is a viable way to build your original database if your system has very little RAM. It cannot see new transactions & blocks without talking to your node however, so you'd never get updates to the chain that way, even if the new block data is written to your disk by Core.

The idea would be to CPFP the tx if it has change.


If you nuked your own Core mempool in the process, it wouldn't be aware of the spentness and fail to help you with this broadcast error. The original issue of low fees on the first tx remains.

This means the transaction you are trying to create is in conflict with another transaction already in the mempool. You need to look into which outputs you are trying to spend, because there is a transaction right now in the network that isn't mined but spends from your outputs. Most likely a former attempt to spend, with a low fee. We can do something about that but first you need to identify the transaction.

Then do what nc50lc suggested:

Core evicts from its mempool transactions that aren't mined within 3 days. With the recent dip in hash rate, there has been over a dozen blocks over 1h since this weekend. Probably your tx was broadcasted but never mined. I suggest you try to send those BTC again but with a manual set fee this time. Something like 150 s/B should get you through.

False negative, next version has a fix for this.



That and a bunch of hash power getting knocked out due to a power outage in China.

Tx will be in your node's mempool past this line. Should be mined by now.

Chances are the tx was broadcasted. You have to start bitcoind with -server at any rate. You wouldn't experience this issue if Armory could talk to Core's RPC.

You should be seeing something in the first few addresses. Where are you sweeping these? Can the destination Doge wallet generate the addresses for these keys? Can you check if these keys had history at any point in time, not just balance?


With Windows, from the command line:

You can also append the arguments in the target field of a shortcut to ArmoryQt.exe.

With Linux, from the terminal:

With OSX:

I had no idea that's even a thing. You can try to run Doge Core, point Armory to the blockchain data (--satoshi-data) and port (--satoshi-port)

Armory has to be read the blockchain (i.e. get online) to know what addresses are in use. Since you are offline, it cannot give you that data from a freshly restored wallet. This is why you need to pick from the set of unused addresses. How many addresses you should export is based on how much activity you have with Doge. If you remember only receiving coins once, export the first 10 addresses (1 for the the received coins, another 9 for the good measure). If you did 10 tx, export the first 30 or so, and so on.

If you have a decent idea of how much Doge you're supposed to have but not how many addresses you used, keep on importing addresses in batches on 10 until you hit that ballpark.

If you have no idea, import the 100 and take it from there (look at transaction history to get an idea how much activity your wallet had).

https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691

Read this post

You do not need to be online to display/export private keys.

Armory's KDF is a precursor of Scrypt. It is mostly memory bound, where the KDF keeps hashing pages upon pages of data that it has to keep in RAM because the final result requires data from unpredictable page indexes. What the user gets to control is the amount of RAM used for the most part. This makes stuff like GPU brute force attacks inefficient.

List looks good, can't really tell you what is missing.

It uses SSE3 and baked in AES, but I think Sandy Bridge had that. Are you running in a VM or on the host?

This issue should be fixed and the code in a better place atm. It's still wonky in places since I'm in the midst of refactoring the giant hardcoded qt gui files, but at least most of what's left over is limited to Qt5 migration and/or refactoring those files. Give it a spin and let me know.

Sounds like whatever you are running this on lacks some amd64 registries. Try the noasm build instead: https://github.com/goatpig/BitcoinArmory/releases/download/v0.96.5/armory_0.96.5_amd64_gcc4.9_noasm.deb