Topic: Loading Armory takes like forever (Read 1747 times)

Well 3rd world peoples could and perhaps should just use a lightweight wallet on the desktop/laptop or most likely, phone. Very few will have the equipment grunt nor the technical patience trying to sort thru the issues.

Let's see dbLog.txt

If all you need is access to your bitcoins, you can simply load Armory offline and extract the private keys which you may then import into other, less resource intensive wallet software.

So,
Armory finished reloading and reorganising everything.

Still no transactions for the wallets and thus no balances either.

after all I did not lost a fortune, hardly half a bitcoin or so. Building an up to date system only to recuperate my wallets will cost me considerably more.

I very much doubt the introduction of bitcoin into 3rd world countries: even though my system is like 2 years old and quit lightweight performancewise it will still outperform compared to 10+ years old hardware with dial-up alike speed restrictions as most really poor people have to rely on.

Best idea is to quit trying I guess ?

Thanks for all the efforts.

still working on the combined 2+3 option and rebuilding the databases again.
My hardware is only 1 year old, but I know it's architecture to be "ancient".
Will decide to build a dedicated BTC stack upon the outcome of several things.

I'll get back when I made some progress.

Meanwhile thanks for your insights.

Not really. The blockchain is bordering 90GB. With the amount of processing required for Core to verify the chain and Armory to parse it, we are in big data territory. Fitting that load on a home hardware is the tough part.

If you think you ought to get a smooth experience trying to setup a full bitcoin stack on what amounts to decade old low end consumer hardware, you need to reassess your expectations.


You can use any non contradictory combination of command line arguments. The specific command you want here is:

a) On Windows, browse to the executable path (in /program files x86/Armory by default), and type the following:

ArmoryDB.exe --db-type=DB_BARE --ram-usage=1

DB_BARE only works on an empty database folder, so you'll have to wipe your current DB, or use another folder.

b) On *nix, in the terminal, input the following:

ArmoryDB --db-type=DB_BARE --ram-usage=1


There are plenty of options as long as you have your private keys in hand. It mostly boils down to user choice. This isn't really the place to discuss these options and what they entail to. It boils down to this:

Any solution that runs off of a full bitcoin node requires a lot of bandwidth, storage and processing power to maintain. With that cost, you buy a full bitcoin experience.

Any solution that does not require a full node will have you give up a set of properties, first among which is your privacy.

Ok, thanks all for your patience.
I somehow understand that my system is not the most powerful in the world, but hey... It is taking some time now, don't you think so?


Just a question : does armoryDB allows the use of 2 options at a time ?
ie : --ram-usage=1   and --db-type=DB_BARE
What would be the correct format ? just a space between both options or something mixed like --ram-usage=1; db-type=DB_BARE ?


Is there any option to restore my BitCoins to another wallet once I have the keylists ?

What about the use of the bitcoin core wallet in combination with paper wallets to store BTC?
Basically I just want to have some control on my BTC mining revenue.
If I send this to a paper wallet with no other step in between I have no chance to check if there's something wrong while transferring

Thanks for your advice.

You are going to have to mix option 2 & 3

No. The private keys are already restored, just that the relevant transactions were not picked up. You can go to the wallet properties and export all off your private keys for that wallet.

First of all your balance is not stored in private keys; that's not how Bitcoin works. Secondly, a wallet is a collection of private keys, so there are multiple keys per wallet.

joy, restarting armory will take another 2 days....

My paper backup only mentions a "root key", this is not the same as a private key.
So I will have to use armory offline to restore the private keys if possible?

Is my balance stored as only 1 private key per wallet or will there be several ?

Go to Help > Rescan Balances and then restart Armory.

Just because you don't see the Bitcoin there does not mean that they are lost. That is not how Bitcoin works, none of the transactions and such are dependent on the wallet. All you need are the private keys, and you still have those.

OK,

So I choose option 1 and let it complete the TX hash scan.
I waited, waited and then waited some more, and yes!, it finally came through!

It displays 'connected' and everything you wish for,
however there is still "a little something" wrong:

All balances on all wallets are empty and there is no sign of transactions, while I am very sure that I made transactions and had positive balances before.

I'm back to loosing all trust in Armory and have the feeling that I should accept that everything's lost in cyberspace thanks to "the most secure platform".--- NOOOOOT !!!!
I'm very glad that I only made some deposites that I had spare, for testing purposes and that my other money is still in a regular bank.

I made paper backups and my best guess now is to see how I can get access to my BTC without using Armory itself.

Or is there a second opinion to this ?

You have a few choices:

1) Let it complete the tx hash scan. This is the last step of the original build & scan.

2) If it seems like it can't pass that stage, delete your DB and rebuild it with --db-type=DB_BARE to skip that part of the scan entirely.

3) If your RAM is still the bottleneck, you can shutdown the bitcoin node while the DB is going through its initial build & scan. That should free enough resources to get through the though part.

Armory DB reports this :

-INFO  - 1479781541: (..\DatabaseBuilder.cpp:268) parsed block file #679
-INFO  - 1479781550: (..\DatabaseBuilder.cpp:268) parsed block file #681
-INFO  - 1479781557: (..\DatabaseBuilder.cpp:268) parsed block file #683
-INFO  - 1479781565: (..\DatabaseBuilder.cpp:268) parsed block file #685
-INFO  - 1479781596: (..\DatabaseBuilder.cpp:268) parsed block file #686
-DEBUG - 1479781596: (..\Blockchain.cpp:242) Organizing chain
-INFO  - 1479796984: (..\DatabaseBuilder.cpp:56) updated HEADERS db in 18208s
-INFO  - 1479796984: (..\BlockUtils.cpp:1636) Enabling zero-conf tracking
-ERROR - 1479798914: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in proc
essDataStackThread: invalid header size
-INFO  - 1479798914: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO  - 1479798914: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node
-ERROR - 1479805166: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in proc
essDataStackThread: invalid header size
-INFO  - 1479805166: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO  - 1479805166: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node
-ERROR - 1479805166: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in proc
essDataStackThread: invalid header size
-INFO  - 1479805167: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO  - 1479805167: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node
-ERROR - 1479805167: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in proc
essDataStackThread: invalid header size
-INFO  - 1479805169: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO  - 1479805169: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node


Should it continue or is something wrong ?
I'm a bit disturbed by the connection/disconnection issue and the invalid header size error

update :
decided to let it continue and it started scanning history and after a while it succeeded:
-INFO  - 1479812709: (..\BlockchainScanner.cpp:225) scanned transaction history
in 257.049s

Now back to QT displaying "Parsing Tx Hashes"
suppose this will take another couple of hours ?

thanks for the warning, I stopped everything first anyhow, there some logic to it :-)

Make sure that armory is stopped first before you delete anything.

ok thanks !
I'll reply when this is done.

You can delete the entire databases folder inside the Armory data folder. This will remove your current database though, but the current database should be rebuilt relatively quickly.

ok, first of all :thanks for your fast! reply !

By following the instructions for superbit, armorydb is running with the  --ram-usage=1 parameter.

 how do I get rid of the 0.93 db ?

You basically have too little RAM to let ArmoryDB run with defaults. You need to run Armory with --ram-usage=1.

You also need to get rid of your 0.93 DB, or point Armory to a fresh db folder using the --dbdir="somenewpath" cli arg.