|
Is there a zombie ArmoryDB.exe process on your system? Are you automating ArmoryDB or running it manually? If manually, is there some other process listening on ArmoryDB's port (9001)?
|
|
|
|
|
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. As stated, Armory reads the block data directly from the "blocks" directory in the "bitcoin home dir". However, it also requires bitcoind/Bitcoin Core to be running so that it can communicate with it via RPC to get notified of new blocks and also send transactions etc.
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. |
|
|
|
3. Check if the transaction on the block explorer is marked as RBF... blockchair.com and mempool.space show pretty clearly whether the transaction is RBF or not... if it is RBF, you can attempt to broadcast a replacement transaction that bumps up the fee... however, given the error that you are getting, it seems like it might not be RBF enabled
The idea would be to CPFP the tx if it has change. When using Armory, I have received no errorm essages at all, when making new transactions after april 19. They just lie there doing nothing. I only got the error message, men posting the transaction in a webpage. Does that not indicate that something is still not ok?
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. |
|
|
|
sendrawtransaction RPC error: {"code":-26,"message":"txn-mempool-conflict"}
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. |
|
|
|
@goatpig
I manually set it to 300 in my failed transaction! double what you suggest it should have cleared within an hour at that fee
Then do what nc50lc suggested: I've checked the Armorylog.txt ( you can share it for others as well) and it's normal to me, but I see that you're still failing to send transactions. If you want, you can broadcast the transaction through other means. To get the signed raw transaction that can be pushed through other services, follow this: - Click "Send Bitcoins", fill up the Amount and Recipient(s) and check "Create Unsigned" then Click "Continue"
- After the info/warning window, click "Copy to Clipboard", then Continue.
- Paste the copied string and click "Sign", type your password and you can now click "Copy Raw Tx (Hex)".
- Submit that to a broadcast service like https://blockstream.info/tx/push or https://live.blockcypher.com/btc/pushtx/ and the transaction should be sent to the network.
if your Armory is having trouble " seeing" transactions from your mempool, you wont see it right away until it get one confirmation. Aside from that, I don't have any other ideas. |
|
|
|
After 4 days of waiting I have cleared the transaction. And the balance restored.
I'm completely stuck.
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. |
|
|
|
And then the error message generated by Armory was inaccurate?
False negative, next version has a fix for this. I'm guessing it was just slow to process due to low fee?
That and a bunch of hash power getting knocked out due to a power outage in China. |
|
|
|
-INFO - 10:08:27.296: (e:\users\goat\code\armory3\cppforswig\bdm_supportclasses.cpp:2118) got getData packet
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.
|
|
|
|
Also, with sweeping it using those pool keys, I did the first handful but the receiving end said they were all empty; I only ever shot a one or two lump amounts to Armory; should I just keep sweeping them one after another until there is a hit?
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? Also, how do I target 'satoshi' etc? like, functionally? I truly dont remember how to do any of this and I feel lost as haha
With Windows, from the command line: ArmoryQt.exe --satoshi-datadir=*somecustompath* --satoshi-port=*somecustomport*
You can also append the arguments in the target field of a shortcut to ArmoryQt.exe. With Linux, from the terminal: ArmoryQt --satoshi-datadir=*somecustompath* --satoshi-port=*somecustomport*
With OSX: |
|
|
|
Seeing as the private key retrieval is not working, how do i get armory to go online so i can manually transfer the DOGE out?
How do I get Armory to correctly target the Doge chain, connected to dogecoin core?
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).
|
|
|
|
- cannot access the actual private key without it being online;
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.
|
|
|
|
This works. What I don't understand though is why the other binary doesn't work even though I have gcc 9.3. Has it been optimized with some instruction set that I don't have on Sandy Bridge?
It uses SSE3 and baked in AES, but I think Sandy Bridge had that. Are you running in a VM or on the host? |
|
|
|
|
Show Posts
