Please help me, I need to access my BTCs, it is all my money.
Extract your private keys and import them into a wallet that is easier to use (and less secure).
Topic: 0.96.1 testing build #4 (Read 8111 times)
Extract your private keys and import them into a wallet that is easier to use (and less secure).
I can't do this here, it's too much of a pain to crawl back through history to figure out what's going on. This is why you don't hijack a thread to ask for help. Make your own.
Please help me, I need to access my BTCs, it is all my money.
Code:
const string BlockDataManagerConfig::defaultDataDir_ =
"~/Armory";
This is where you find your logs. Otherwise extract them from the file menu option.
I do not understand what I do with this?
I just upgraded to 0.96.1 from the newest sticked thread, same problem.
ArmoryDB.exe always crashes at "Scanning Transaction History" , I am not able to access my BTCs since weeks and that is much money..
Where do I find them?
logs
I use 0.96.0.4 and cannot access my BTCs since then.
ArmoryDB.exe always crashes at "Scanning Transaction History" at 98 or 99%.
ArmoryDB.exe always crashes at "Scanning Transaction History" at 98 or 99%.
i didn't get an answer to this in the other thread so i thought i'd post it here:
is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok.
getblockcount shows correct height.
is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok.
getblockcount shows correct height.
Connected only means the DB is connected to a node over the P2P layer. The block height is what your DB sees as the longest chain. If it's behind your node, your DB has an issue. Try 0.96.0.4, it fixes a lot of that stuff.
i didn't get an answer to this in the other thread so i thought i'd post it here:
is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok.
getblockcount shows correct height.
is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok.
getblockcount shows correct height.
Quote
Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count?
I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple?
I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple?
I'd have to look into it.
Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.
Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.
That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail.
My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code.
I've found one folder I'd been using for storing unsigned transactions, in order to use them over different local user accounts. The folder is called "Öffentlich" in german, although Windows works with given folder names in english in the background anyway. But it seem I've called another folder "Öffentlich ..." in that same dir that was custom. So I've renamed it to "Oeffentlich". Wallet didn't seem to be affected by this, since Armory couldn't find any errors and when I try to enter a non-ascii characted in any label I automatically receive an error prompt message.
What's more problematic are the custom folders, because for e.g. in german you have many characters which are not ascii compatible.
Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count?
I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple?
Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.
Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.
That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail.
My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code.
Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.
Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.
Regarding Bug #1: I'm using the german locale [Deutsch (de)].
Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.
BUG #1:
Cannot reproduce, never was able to. What locale are you using?
BUG #2:
Do not use auto bitcoind. Also build the current state of testing.
Cannot reproduce, never was able to. What locale are you using?
BUG #2:
Do not use auto bitcoind. Also build the current state of testing.
Regarding Bug #1: I'm using the german locale [Deutsch (de)].
Bug #2: I've completed a rebuild & rescan with some block deser errors, but managed to run through anyway. So it seems to work now, but with build #3. I'm going to test build #4 on another machine seperatly.
Kind regards :-)
BUG #1:
Cannot reproduce, never was able to. What locale are you using?
BUG #2:
Do not use auto bitcoind. Also build the current state of testing.
Cannot reproduce, never was able to. What locale are you using?
BUG #2:
Do not use auto bitcoind. Also build the current state of testing.
Hey goatpig!
I've tested the new build "Armory 0.96.0.4-testing". I'm recalling on the address book issue - BUG #1 - (address selection via "select address" button).
There is also an major issue with Bug #2 (see beneath).
Altough the offline tx file loading bug has now been solved with this version!
------------------------------------------------------------------------------------------------------------------------------------------------
BUG #1
Select Wallet > Send > Open address book > Select address
This button is also still broken (like double-click). Addresses can only be chosen via the address book by right-click copy address and paste it into the address field in the sending dialoge.
armorylog.txt
------------------------------------------------------------------------------------------------------------------------------------------------
BUG #2
Executing ArmoryQt > The first progress bar isn't displayed (ArmoryDB takes a little bit longer to initialize) > Armory has now started ArmoryDB and grabs existing block data > Armory loaded but isn't able to connect to bitcoind
This issue occurs from time to time and the only solution is to restart the PC and then start ArmoryQt again after reboot. But after this I get very often POLLER Errors and "raw blockchain data doesn't match expected block hash" Errors. So I need to to Rebuild & Rescan. I have no AV installed and Windows Defender already has exceptions for every Program associated with Armory and Bitcoin Core. So I have no clue why this happens again.
dbLog.txt (No.1)
dbLog.txt (No.2)
------------------------------------------------------------------------------------------------------------------------------------------------
I've tested the new build "Armory 0.96.0.4-testing". I'm recalling on the address book issue - BUG #1 - (address selection via "select address" button).
There is also an major issue with Bug #2 (see beneath).
Altough the offline tx file loading bug has now been solved with this version!
------------------------------------------------------------------------------------------------------------------------------------------------
BUG #1
Select Wallet > Send > Open address book > Select address
This button is also still broken (like double-click). Addresses can only be chosen via the address book by right-click copy address and paste it into the address field in the sending dialoge.
armorylog.txt
Code:
2017-07-19 09:31:00 (ERROR) -- Traceback (most recent call last):
File "qtdialogs.pyc", line 8091, in acceptAddrSelection
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 4: ordinal not in range(128)
------------------------------------------------------------------------------------------------------------------------------------------------
BUG #2
Executing ArmoryQt > The first progress bar isn't displayed (ArmoryDB takes a little bit longer to initialize) > Armory has now started ArmoryDB and grabs existing block data > Armory loaded but isn't able to connect to bitcoind
This issue occurs from time to time and the only solution is to restart the PC and then start ArmoryQt again after reboot. But after this I get very often POLLER Errors and "raw blockchain data doesn't match expected block hash" Errors. So I need to to Rebuild & Rescan. I have no AV installed and Windows Defender already has exceptions for every Program associated with Armory and Bitcoin Core. So I have no clue why this happens again.
dbLog.txt (No.1)
Code:
-INFO - 09:21:45.047: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO - 09:21:45.219: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:249) Listening on port 52144
-INFO - 09:21:45.344: (..\BlockUtils.cpp:1092) Executing: doInitialSyncOnLoad
-INFO - 09:21:45.391: (..\DatabaseBuilder.cpp:190) Reading headers from db
-INFO - 09:21:48.203: (..\BDM_Server.cpp:1074) registered bdv: 87a75e5d94283b58e55b
-WARN - 09:23:13.500: (..\Blockchain.cpp:63) block id duplicate: 476093
-INFO - 09:24:19.188: (..\DatabaseBuilder.cpp:229) Found 475996 headers in db
-INFO - 09:24:21.438: (..\DatabaseBuilder.cpp:63) Rewinding 100 blocks
-INFO - 09:24:21.438: (..\DatabaseBuilder.cpp:70) updating HEADERS db
-INFO - 09:24:28.766: (..\DatabaseBuilder.cpp:272) parsed block file #937
-INFO - 09:24:29.610: (..\DatabaseBuilder.cpp:272) parsed block file #938
-INFO - 09:24:30.610: (..\DatabaseBuilder.cpp:482) Found next block after skipping 998205bytes
-INFO - 09:24:31.500: (..\DatabaseBuilder.cpp:272) parsed block file #939
-INFO - 09:24:31.500: (..\Blockchain.cpp:246) Organizing chain
-INFO - 09:24:31.563: (..\Blockchain.cpp:360) Organized chain in 0.062s
-INFO - 09:24:31.719: (..\DatabaseBuilder.cpp:75) updated HEADERS db in 10.283s
-INFO - 09:24:31.719: (..\DatabaseBuilder.cpp:1121) verifying txfilters integrity
-INFO - 09:26:09.266: (..\DatabaseBuilder.cpp:1205) done checking txfilters
-INFO - 09:26:09.875: (..\DatabaseBuilder.cpp:127) scanning new blocks from #475996 to #476432
-INFO - 09:26:11.578: (..\BlockchainScanner.cpp:665) scanned from height #475996 to #476432
-INFO - 09:26:11.703: (..\BlockchainScanner.cpp:225) scanned transaction history in 1.813s
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:313) gc count: 5
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:314) peak: 5
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:316) file id: 935
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:316) file id: 936
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:316) file id: 937
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:316) file id: 938
-INFO - 09:26:11.703: (..\BlockDataMap.cpp:316) file id: 939
-INFO - 09:26:11.953: (..\DatabaseBuilder.cpp:177) scanned new blocks in 2.083s
-INFO - 09:26:11.953: (..\DatabaseBuilder.cpp:181) init db in 266.61s
-INFO - 09:26:11.953: (..\BDM_supportClasses.cpp:1873) Enabling zero-conf tracking
-ERROR - 09:28:12.578: (..\SocketObject.cpp:290) POLLERR error in readFromSocketThread
-ERROR - 09:28:12.672: (..\BitcoinP2P.cpp:1027) caught SocketError exception in processDataStackThread: POLLERR error in readFromSocketThread
dbLog.txt (No.2)
Code:
-INFO - 09:45:43.125: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO - 09:45:44.484: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:249) Listening on port 56843
-INFO - 09:45:44.906: (..\BlockUtils.cpp:1092) Executing: doInitialSyncOnLoad
-INFO - 09:45:44.015: (..\DatabaseBuilder.cpp:190) Reading headers from db
-INFO - 09:45:45.953: (..\BDM_Server.cpp:1074) registered bdv: 98376ae835966ed6a09e
-WARN - 09:46:43.343: (..\Blockchain.cpp:63) block id duplicate: 476093
-INFO - 09:47:18.406: (..\DatabaseBuilder.cpp:229) Found 476433 headers in db
-INFO - 09:47:20.515: (..\DatabaseBuilder.cpp:63) Rewinding 100 blocks
-INFO - 09:47:20.515: (..\DatabaseBuilder.cpp:70) updating HEADERS db
-INFO - 09:47:22.484: (..\DatabaseBuilder.cpp:482) Found next block after skipping 997872bytes
-INFO - 09:47:22.546: (..\DatabaseBuilder.cpp:272) parsed block file #939
-INFO - 09:47:23.750: (..\Blockchain.cpp:246) Organizing chain
-INFO - 09:47:23.796: (..\Blockchain.cpp:360) Organized chain in 0.047s
-INFO - 09:47:23.812: (..\DatabaseBuilder.cpp:75) updated HEADERS db in 3.297s
-INFO - 09:47:23.812: (..\DatabaseBuilder.cpp:1121) verifying txfilters integrity
-INFO - 09:47:58.750: (..\DatabaseBuilder.cpp:1205) done checking txfilters
-INFO - 09:47:58.078: (..\DatabaseBuilder.cpp:127) scanning new blocks from #476433 to #476441
-INFO - 09:47:59.500: (..\BlockchainScanner.cpp:665) scanned from height #476433 to #476441
-INFO - 09:47:59.500: (..\BlockDataMap.cpp:313) gc count: 1
-INFO - 09:47:59.500: (..\BlockDataMap.cpp:314) peak: 1
-INFO - 09:47:59.500: (..\BlockDataMap.cpp:316) file id: 939
-INFO - 09:47:59.562: (..\DatabaseBuilder.cpp:177) scanned new blocks in 0.485s
-INFO - 09:47:59.562: (..\DatabaseBuilder.cpp:181) init db in 134.655s
-INFO - 09:47:59.562: (..\BDM_supportClasses.cpp:1873) Enabling zero-conf tracking
-INFO - 09:51:18.796: (..\BitcoinP2P.cpp:947) Connected to Bitcoin node
-INFO - 09:55:10.062: (..\DatabaseBuilder.cpp:482) Found next block after skipping 17845bytes
-INFO - 09:58:33.625: (..\BlockchainScanner.cpp:665) scanned from height #476442 to #476442
-WARN - 10:02:26.515: (..\BDM_supportClasses.cpp:1937) running 10 zc parser threads
-INFO - 10:02:27.765: (..\BlockchainScanner.cpp:665) scanned from height #476443 to #476443
-INFO - 10:04:52.937: (..\BlockchainScanner.cpp:665) scanned from height #476444 to #476446
-INFO - 10:05:58.796: (..\BlockchainScanner.cpp:665) scanned from height #476447 to #476447
-INFO - 10:07:01.515: (..\BlockchainScanner.cpp:665) scanned from height #476448 to #476448
-INFO - 10:07:41.765: (..\BlockchainScanner.cpp:665) scanned from height #476449 to #476449
-INFO - 10:08:36.890: (..\BlockchainScanner.cpp:665) scanned from height #476450 to #476450
-INFO - 10:09:10.609: (..\BlockchainScanner.cpp:665) scanned from height #476451 to #476451
-INFO - 10:10:00.812: (..\BlockchainScanner.cpp:665) scanned from height #476452 to #476452
-WARN - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 15 zc parser threads
-WARN - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 20 zc parser threads
-WARN - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 25 zc parser threads
-WARN - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 30 zc parser threads
-ERROR - 10:10:53.734: (..\BlockchainScanner.cpp:271) raw data does not match expected block hash
Jump to: