|
dbLog.txt, just post that file here, we'll go over it.
|
|
|
|
When I'm trying to send BTC with the "Auto fee byte" option checked and "enable RBF" unchecked I'm receiving the message "This is lower than the suggested minimum fee rate of 200 sat/B", I can decide whether I want to continue with this low fee or not. After choosing "yes" simply nothing happens. I decided to enable RBF and up the fee rate to the suggested 200 sat/B, after pressing "Send!" it is just not reacting, seems like Armory is not "receiving" the input. My explanation for this was that RBF is not working by default like I was told earlier in this thread.
Show me your logs. |
|
|
|
Still working on the migration to qt5.
Any ETA?  Im not good with ETAs, don't ask. Soon (TM) |
|
|
|
|
Still working on the migration to qt5.
|
|
|
|
The previous scheme weakened the security of the fragments to yield the identical IDs each run. It essentially salted the fragments with a hash of the private key when that value should be random. The security impact isn't dire but it is eroded so I chose to fix the issue even it meant some backwards compatibility issue. Essentially, backups created prior to the fix will display fragment IDs that are different from what the fixed ArmoryQt will display. As long as the walletID matches at the end of the process, you should be all good. In fact, on the "Restore wallet fragments" window I get no indication I've done anything.
Would need to see the logs to figure that out. but it shows a balance of 0l.0 because that machine never got the entire blockchain and frankly it's so slow I really don't want to spend a week with it pulling down the blockchain only to maybe have the same problem.
Please don't try to restore your wallet on an online machine unless you have no other option (even then, get a cheap PC, don't be lazy). Once the wallet is restored, extract a watching only copy and use that on your online machine to sync with the chain. |
|
|
|
it's telling me that it cannot open the cryptoapp.lib
You have to build cryptopp and leveldb manually (right click on the project and build it). |
|
|
|
|
At least someone got this thing working, I was losing hope =D
|
|
|
|
-ERROR - : (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
is this a clue? Something else than ArmoryDB is listening on the port that ArmoryQt connection to. |
|
|
|
|
Post your logs for inspection. You can grab them from Armory in the Files menu.
|
|
|
|
|
That file only contains address hashes, no private data exists in there.
|
|
|
|
Browse to the install folder (in /usr/lib i believe) and: |
|
|
|
|
Start ArmoryDB on its from the command line then start ArmoryQt, report both logs in here.
|
|
|
|
$ sudo apt-get install libqtcore4 python-qt4 python-dev python-twisted python-psutil
These are the dependencies for Ubuntu to run Armory |
|
|
|
FO - 02:03:35: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 02:03:35: (BDM_Server.h:263) Listening on port 9001
-INFO - 02:03:35: (BlockUtils.cpp:1108) Executing: doInitialSyncOnLoad
-INFO - 02:03:35: (DatabaseBuilder.cpp:199) Reading headers from db
-INFO - 02:03:40: (DatabaseBuilder.cpp:238) Found 663421 headers in db
-INFO - 02:03:43: (DatabaseBuilder.cpp:64) Rewinding 100 blocks
-INFO - 02:03:43: (DatabaseBuilder.cpp:71) updating HEADERS db
-INFO - 02:03:43: (Blockchain.cpp:248) Organizing chain
-INFO - 02:03:43: (Blockchain.cpp:370) Organized chain in 0s
-INFO - 02:03:43: (DatabaseBuilder.cpp:76) updated HEADERS db in 0s
-INFO - 02:03:43: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 02:03:43: (DatabaseBuilder.cpp:1231) verifying txfilters integrity
-INFO - 02:03:51: (DatabaseBuilder.cpp:1314) done checking txfilters
-INFO - 02:03:51: (DatabaseBuilder.cpp:134) scanning new blocks from #663421 to #663420
-INFO - 02:03:51: (BlockchainScanner.cpp:52) no history to scan
-INFO - 02:03:51: (BlockchainScanner.cpp:1021) no SSH to scan
-INFO - 02:03:51: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 02:03:51: (DatabaseBuilder.cpp:186) scanned new blocks in 0s
-INFO - 02:03:51: (DatabaseBuilder.cpp:190) init db in 16s
-INFO - 02:03:51: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
From this snippet, ArmoryDB is up and running fine, what you need is for ArmoryQt to connect to it. This typically happens as is when you just start it. Please run ArmoryQt from the terminal while ArmoryDB is running and report the result here. Full logs are preferred, as mentioned earlier. |
|
|
|
|
1. Make sure ArmoryDB isn't running
2. Run ArmoryDB from the terminal, it shouldn't require any arguments for now
3. Start ArmoryQt from another terminal, it should connect to ArmoryDB. Report here at any rate.
|
|
|
|
|
There is something stopping ArmoryQt from connecting to ArmoryDB, probably a port conflict. You should start ArmoryDB manually then start ArmoryQt, see how that goes.
|
|
|
|
I can't send to a SegWit address (starting with either a 3 or bc1).
Armory detects this, it will grey out segwit addresses at creation. You cannot use Armory to create segwit addresses under these conditions, but you can send to nested segwit regardless (addy starting with 3). Still looking into this, but I suspect the answer is yes and no,
The DB can handle it, the underlying file format and the P2P layer are compatible. RPC will be busted most likely, which degrades the utility somewhat, but it's not a deal breaker. You won't get fee estimates, Core status updates nor boardcast fallbacks. |
|
|
|
|
There is a process listening on the port armorydb.exe is trying to use. The client is connecting to the expected port and speaking FCGI to it, and getting something unexpected in return, meaning it's not talking to the DB.
|
|
|
|
|
Show Posts
