Now i have run into problems with viewing previous transactions. (Mainnet). Receiving transactions no longer contain the sending addresses or any info about that. Sending transactions error out unless the transaction was sent with change or sent to another armory wallet. The GUI error states:
"Invalid Tx. The transaction you requested be displayed does not exist in Armory's database. This is unusual..." According to the log: \lmdb_wrapper.cpp:707 txhash is less than 4 bytes long.
This is a design choice. This change was part of the original 0.94 too, when it was in testing about a year ago.
I'll reexplain the decision for the sake of clarity:
Bitcoin transactions are referred to each other by tx hash. Block data is ordered by height in the longest chain. While you can refer to a block either by its header hash or its height in the main chain, the blockchain does not provide any data to resolve a transaction hash to its specific block.
Since there is no quick way to resolve tx hashes to actual transaction data, it befalls on the next layer (in this case Armory's DB engine) to maintain enough data for that purpose. In Armory, this particular feature is called the TxHint database. It keys the 4 first bytes of each tx hash found in the chain with its potential block height and tx index.
This database is generally pretty slow. Since the entries are keyed by hash and hashes do not appear in order in the chain (why would they?), this DB is very fragmented. Moreover, searches in this dataset are usually completely random, so there is little room to optimize the access speed.
This DB is also pretty large. With the current blockchain (~50GB), it's closing on 5GB of data. Such a large and fragmented dataset will grind any HDD to a halt. SSDs will be fine though.
With these parameters in mind, what is this DB used for? In fullnode it only serves 2 purposes:
1) Resolve funding txouts
2) Calculate the fee paid by the sender.
The way transactions are scanned, you will always know the txhash of the transactions you spent from. What you lack is the hash of the transactions that funded your wallet from addresses that are unknown to your wallets, i.e. you have the txhints for your spends, change and all inter wallet transactions, but you are missing hints for any outside coins coming in.
The choice was simple: the current fullnode DB averages 150MB on mainnet, with the txhint DB, you have to add another 5GB to support a non critical dataset, that is only really used in 2 dialogs hidden behind a few clicks. I made the decision before and I am doing it again to remove that dataset from fullnode's default feature.
Now, if there is enough demand to get the full TxHint DB back as an option in fullnode, I will add a command line argument to support the feature for savvy users.
The scan was concerning at first because it kept updating at 31%, 63% 95% and then starting over at 0%. According to the log file this must of happened when the blockchainScanner scanned from intermediate heights. (Eg. #397557 to #398370, #398371 to #399115, etc, etc)
This should happen when the scan fails and the DB is fixing itself (there is an auto repair code that kicks in when the scan doesn't end gracefully). Are your balances valid atm? Do you experience this issue when you rescan? What about rebuild & rescan?
I also had this problem with the transaction history progress bar. I thought it might be stuck in a loop (was probably just taking ages due to my old pc) so I closed and restarted Armory. On restarting, it failed to continue the transaction scan and showed my balance from (I believe) the point at which I'd closed Armory.
I'll investigate. What version of Core are you using?
