BitMaxz -- CPU is AMD Phenom II X4 960T 3.4 GigaHz, 64 bit W7.  Sometimes I have shut it down by accident before closing bitcoin core.  

I performed -reindex by adding it as a flag to the Windows shortcut that opens bitcoin core.  So, I use the flags:   -datadir=F:\Bitcoin -reindex tacked onto the bitcoin-qt.exe call in the shortcut.  My W7 box connects to the NAS this way -- F is a samba share.

---

ETFbitcoin -- thanks for the suggestion.  I tried moving all the files inside the "index" folder then running Bitcoin Core with -reindex but it immediately abended with the same error as before.  Here is the log created by my attempt to follow your suggestion:

-------------------------------------------
2022-09-02T17:45:39Z Bitcoin Core version v22.0.0 (release build)
2022-09-02T17:45:39Z Qt 5.12.11 (static), plugin=windows (static)
2022-09-02T17:45:39Z Static plugins:
2022-09-02T17:45:39Z  QWindowsIntegrationPlugin, version 330752
2022-09-02T17:45:39Z  QWindowsVistaStylePlugin, version 330752
2022-09-02T17:45:39Z Style: windowsvista / QWindowsVistaStyle
2022-09-02T17:45:39Z System: Windows 7 SP 1 (6.1), x86_64-little_endian-llp64
2022-09-02T17:45:39Z Screen: \\.\DISPLAY1 1920x1200, pixel ratio=1.0
2022-09-02T17:45:41Z Assuming ancestors of block 00000000000000000008a89e854d57e5667df88f1cdef6fde2fbca1de5b639ad have valid signatures.
2022-09-02T17:45:41Z Setting nMinimumChainWork=00000000000000000000000000000000000000001fa4663bbbe19f82de910280
2022-09-02T17:45:41Z Using the 'standard' SHA256 implementation
2022-09-02T17:45:41Z GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely…"
2022-09-02T17:45:41Z Default data directory C:\Users\Ted\AppData\Roaming\Bitcoin
2022-09-02T17:45:41Z Using data directory F:\Bitcoin
2022-09-02T17:45:41Z Config file: F:\Bitcoin\bitcoin.conf
2022-09-02T17:45:41Z Command-line arg: datadir="F:\\Bitcoin"
2022-09-02T17:45:41Z Command-line arg: reindex=""
2022-09-02T17:45:41Z Using at most 125 automatic connections (2048 file descriptors available)
2022-09-02T17:45:41Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2022-09-02T17:45:41Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2022-09-02T17:45:41Z Script verification uses 3 additional threads
2022-09-02T17:45:41Z scheduler thread start
2022-09-02T17:45:41Z Using wallet directory F:\Bitcoin
2022-09-02T17:45:41Z init message: Verifying wallet(s)…
2022-09-02T17:45:41Z init message: Loading banlist…
2022-09-02T17:45:41Z SetNetworkActive: true
2022-09-02T17:45:41Z Using /16 prefix for IP bucketing
2022-09-02T17:45:41Z Cache configuration:
2022-09-02T17:45:41Z * Using 2.0 MiB for block index database
2022-09-02T17:45:41Z * Using 8.0 MiB for chain state database
2022-09-02T17:45:41Z * Using 290.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2022-09-02T17:45:41Z init message: Loading block index…
2022-09-02T17:45:41Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2022-09-02T17:45:41Z Wiping LevelDB in F:\Bitcoin\blocks\index
2022-09-02T17:45:41Z boost::filesystem::status: Access is denied: "F:\Bitcoin\blocks\index"
2022-09-02T17:45:41Z Error: Error opening block database
2022-09-02T17:45:45Z Shutdown: In progress...
2022-09-02T17:45:45Z scheduler thread exit
2022-09-02T17:45:45Z Shutdown: done

---

The whole idea of leaving the datadir on the NAS was to not need to re-download the entire blockchain WHEN something like this happened.  I'm pretty disappointed with the Bitcoin Core program.  For lack of alternatives, I will probably have to delete the blocks and start all over.  Given my experience, I probably won't use the NAS next time and eventually, I will try to navigate away from needing Bitcoin Core because it creates problems for me.

Thank you for the additional suggestions.

I know my Windows is a 64 bit version.  I'm away from that PC until next week but I will find more of the system specs (such as the CPU Model) and try your suggestion ETFbitcoin.

Personally, I have always thought the slow performance with the bitcoin core client was due to it being behind 2 firewalls with no port forwarding to accept incoming connections from the bitcoin network. I'm not willing to change that for the workstation the bitcoin core client runs on so I didn't see a way to research the slow performance downloading blocks.  But I have noticed depending on the day, that the client would have problems accessing peers.

Thank you for the numerous list of suggestions of other things for me to investigate (rather than asking for assistance with the bitcoin core client here.) 

My PC has 6 Gb of RAM, it does have a SSD (which all programs, including the Bitcoin Core, run from), the OS is Windows 7.  The NAS works fine with all the other devices connected to it.  Someday I guess I will benchmark it in my spare time. 

There surely must be some other detail(s) some of you could find for me to not expect the bitcoin core software to work and give up on the question I asked?


 

I'm using v.22 of the bitcoin core client on an old Windows box.  I have the data directory set to use my NAS and have used it successfully in this configuration for several years.

The debug.log contains the following:
-------------------------------------------------------------------------------------
2022-08-24T19:06:30Z Opening LevelDB in F:\Bitcoin\blocks\index
2022-08-24T19:06:30Z Fatal LevelDB error: IO error: F:\Bitcoin\blocks\index/CURRENT: Access is denied.\x0d

2022-08-24T19:06:30Z You can use -debug=leveldb to get more complete diagnostic messages
2022-08-24T19:06:30Z Fatal LevelDB error: IO error: F:\Bitcoin\blocks\index/CURRENT: Access is denied.\x0d

2022-08-24T19:06:30Z : Error opening block database.
-------------------------------------------------------------------------------------

I have tried deleting the CURRENT file but that caused some other kind of early abnormal termination of the bitcoin client program so I replaced it.  I also tried rolling the data directory back in time a couple months using an incremental backup from my NAS, to no avail:  I get the same error afterwards.  I also tried the -reindex option but that also errors out with the same message.  I see the following in debug.log after trying with the -reindex option:

-------------------------------------------------------------------------------------
2022-08-24T19:25:01Z init message: Loading block index…
2022-08-24T19:25:01Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2022-08-24T19:25:01Z Opening LevelDB in F:\Bitcoin\blocks\index
2022-08-24T19:25:01Z Fatal LevelDB error: Corruption: 53 missing files; e.g.: F:\Bitcoin\blocks\index/001702.ldb
2022-08-24T19:25:01Z You can use -debug=leveldb to get more complete diagnostic messages
2022-08-24T19:25:01Z Fatal LevelDB error: Corruption: 53 missing files; e.g.: F:\Bitcoin\blocks\index/001702.ldb
2022-08-24T19:25:01Z : Error opening block database.
Please restart with -reindex or -reindex-chainstate to recover.
2022-08-24T19:25:08Z init message: Loading block index…
2022-08-24T19:25:08Z should not be overwriting a chainstate
2022-08-24T19:25:08Z Error: Error opening block database
2022-08-24T19:25:09Z Shutdown: In progress...
2022-08-24T19:25:09Z scheduler thread exit
2022-08-24T19:25:09Z Shutdown: done
-------------------------------------------------------------------------------------

Can anyone suggest a way that might let me recover from this error?  For whatever reason, I'm pretty sure it will take my hardware days or more likely, months, to re-download the blockchain.  That's why I keep it on the NAS with multiple generations of backups.

Someone, maybe on reddit, was asking how this applies to bitcoin.  Well, the answer to protecting private keys recorded as QR codes, he comes up with is to use memory-hard encryption that takes 60 seconds to validate an attempt.  For me, that type of protection would be the holy grail that would let me keep backups of my paper wallet(s) as QR codes without having to worry about securing the QR code somehow (in a vault, etc).

Did anyone else get excited about that part of Steve Gibson's thoughts about how to implement his SQRL authentication idea?  That part is perfect for bitcoin users.  I am hoping it inspires ethiopei to implement that kind of encryption on armory paper wallets.

Kind of reminds you of another reason to be interested in Bitcoins in the first place! 

I'll try to help, I did this for the first time a few days ago.

After adding Bitstamp as a BTC issuer, you need to "trust" them to exchange the ripple BTC IOU's for genuine BTC.  This is done by Advanced --> Trust --> Green + sign, then paste the ripple address of Bitstamp and click save.

After that, on the left hand side, click Trade, use the dropdown to choose BTC/XRP.  Click Order Book near the bottom of that page and you should see a fairly active order book like you would at a Bitcoin exchange.   

rGxQW9G5NEZGPP8vVEVi4RH9T3A4rhQJ9e

Ditto with the earlier poster:  I think the price would go down quite a bit.

Sure, the exchanges aren't in USA, but the bank accounts of most of the customers are.  All it would take is a government not permitting banks to do business with the exchanges by branding them "sponsors of terror" and few users will want to deal with the inconvenience.  The US growth, which is most of the engine of growth, would die quickly because it would become too inconvenient for potential new users to buy coins to use for regular transactions.  It could live on in other countries, but it would set it back several years in terms of valuation and usefulness to the current users...

Just tried the updated 0.82.1 for W64, no freezing on-load problem.     Haven't tested any more than starting it up a couple times.

True, but don't you think that if too many of the players bet this way, the house is more likely to bust?  The table bet limits are the house's friend.

Thanks for the suggestions.  The small usb idea, was just for me, not something I was advocating for all armory users to mess with.  Don't get me wrong, I really like Armory.  After spending a long time looking at alternatives, I decided Armory is the closest alternative to a perfect solution that is out there.  Most of the paper wallet solutions available, really are not truly "offline" solutions to me when the private keys have to, eventually, enter something that runs online where, practically speaking, the environment cannot be guaranteed to always be 100% secure.  Only using the paper wallets to send once & then sending the change to a new one, was one idea, but that seemed like it would get confusing to me after doing it for a while.  Armory is the only easy-to-use solution I could find, that doesn't have you trusting an online environment, or relying on a web page that might not be there someday, to transmit the signed transaction.

Having thought about the weakest point though, I would like armory a little better if it printed OCR codes to return the signed transaction to the online wallet to transmit.

For a USB, I'm happy trying a solution that will work for *most* transactions I might make, maybe enlarging the partition or moving to new keys with no transaction history, as my previous transactions eventually grow too long.  I will give it a try.

Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory.  I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet. 

I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large).  As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries.  I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.

Tried it again & no delay on first run, but not when I tried to see where the update setting was left under Help -->.

Here is the log from just before the errors begin:
2012-07-15 19:09 (INFO) -- ArmoryQt.py:350 - Loading blockchain took 59.3 seconds
2012-07-15 19:09 (INFO) -- ArmoryQt.py:403 - Usermode: Expert
2012-07-15 19:09 (INFO) -- ArmoryQt.py:704 - Changing usermode:
2012-07-15 19:09 (INFO) -- ArmoryQt.py:705 -    From: Expert
2012-07-15 19:09 (INFO) -- ArmoryQt.py:713 -      To: Expert
2012-07-15 19:09 (INFO) -- ArmoryQt.py:2525 - Another Armory instance just tried to open.
2012-07-15 19:09 (INFO) -- ArmoryQt.py:755 - User requested never check for new versions
2012-07-15 19:09 (INFO) -- armoryengine.pyc:9084 - Handshake finished, connection open!
2012-07-15 19:17 (ERROR) -- ArmoryQt.py:782 - Could not access latest Armory version information
2012-07-15 19:17 (ERROR) -- ArmoryQt.py:783 - Tried: https://raw.github.com/etotheipi/BitcoinArmory/logger/versions.txt

After it unfroze, went to Help --> Armory Version and had no delay at all seeing the message that a new version was available, I tried that several times in a row, no delays and no more log entries being created to share. 

Going to Help --> Armory Versions, I clicked on "Never again", restarted Armory & it worked fine--no abnormal delay.  Then I went to Help --> Armory Versions to try to change it back.  Before I could select anything, there was a long delay again (>5min?), followed by a dialog box saying "The latest Armory version information could not be retrieved.Please check www.bitcoinarmory.com for the latest version information."  I clicked OK and it seems to be working normally. 

I tried a signed offline transaction and 0.82.1, Windows 64 bit version worked fine except for the above.  Thanks for promptly upgrading the python library btw.

Version 0.82.1, Windows 64 bit version, starts OK for me.  But after loading the blockchain, it freezes for like 5 minutes and looks like it's not going to start.  After that, it seems to run OK.  Yet to try doing transactions with it though...

Here is log.
2012-07-15 11:49 (INFO) -- armoryengine.pyc:489 - ************************************************************
2012-07-15 11:49 (INFO) -- armoryengine.pyc:490 - Invoked: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe --satoshi-datadir=<<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:491 - ************************************************************
2012-07-15 11:49 (INFO) -- armoryengine.pyc:492 - Loading Armory Engine:
2012-07-15 11:49 (INFO) -- armoryengine.pyc:493 -    Armory Version        : 0.82.1
2012-07-15 11:49 (INFO) -- armoryengine.pyc:494 -    PyBtcWallet  Version  : 1.35
2012-07-15 11:49 (INFO) -- armoryengine.pyc:495 - Detected Operating system: Windows
2012-07-15 11:49 (INFO) -- armoryengine.pyc:496 -    User home-directory   : <<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:497 -    Satoshi BTC directory : <<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:498 -    Armory home dir       : <<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:499 -
2012-07-15 11:49 (INFO) -- armoryengine.pyc:500 - Network Name: Main Network
2012-07-15 11:49 (INFO) -- armoryengine.pyc:501 - Satoshi Port: 8333
2012-07-15 11:49 (INFO) -- armoryengine.pyc:502 - Named options/arguments to armoryengine.py:
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     logDisable      : False
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     settingsPath    : <<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     nettimeout      : 2
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     doDebug         : False
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     testnet         : False
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     datadir         : DEFAULT
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     satoshiHome     : <<snip>>
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     offline         : False
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     interport       : 8223
2012-07-15 11:49 (INFO) -- armoryengine.pyc:504 -     logcpp          : False
2012-07-15 11:49 (INFO) -- armoryengine.pyc:505 - Other arguments:
2012-07-15 11:49 (INFO) -- armoryengine.pyc:508 - ************************************************************
2012-07-15 11:49 (INFO) -- armoryengine.pyc:643 - C++ block utilities loaded successfully
2012-07-15 11:49 (INFO) -- armoryengine.pyc:9212 - Using settings file: <<snip>>
2012-07-15 11:49 (INFO) -- ArmoryQt.py:1073 - Loading wallets...
2012-07-15 11:49 (INFO) -- ArmoryQt.py:1121 - Number of wallets read in: 1
2012-07-15 11:49 (INFO) -- ArmoryQt.py:1126 -    Wallet (<<snip>>):   "<<snip>>   "   (No Encryption)
2012-07-15 11:49 (INFO) -- ArmoryQt.py:834 - Setting up networking...
2012-07-15 11:49 (INFO) -- ArmoryQt.py:885 - Internet connection is Available: True
2012-07-15 11:49 (INFO) -- ArmoryQt.py:886 - Bitcoin-Qt/bitcoind is Available: True
2012-07-15 11:49 (INFO) -- ArmoryQt.py:1217 - Loading blockchain
2012-07-15 11:50 (WARNING) -- ArmoryQt.py:1271 - Memory pool file was corrupt.  Deleted. (no further action is needed)
2012-07-15 11:50 (INFO) -- ArmoryQt.py:1228 - Syncing wallets with blockchain...
2012-07-15 11:50 (INFO) -- ArmoryQt.py:1230 - Syncing wallet: <<snip>>
2012-07-15 11:50 (INFO) -- ArmoryQt.py:350 - Loading blockchain took 76.1 seconds
2012-07-15 11:50 (INFO) -- ArmoryQt.py:403 - Usermode: Expert
2012-07-15 11:50 (INFO) -- ArmoryQt.py:704 - Changing usermode:
2012-07-15 11:50 (INFO) -- ArmoryQt.py:705 -    From: Expert
2012-07-15 11:50 (INFO) -- ArmoryQt.py:713 -      To: Expert
2012-07-15 11:57 (ERROR) -- ArmoryQt.py:780 - Could not access latest Armory version information
2012-07-15 11:57 (ERROR) -- ArmoryQt.py:781 - Tried: https://raw.github.com/etotheipi/BitcoinArmory/logger/versions.txt
2012-07-15 11:57 (INFO) -- ArmoryQt.py:2523 - Another Armory instance just tried to open.
2012-07-15 11:57 (INFO) -- armoryengine.pyc:9084 - Handshake finished, connection open!

They found an outgoing stream from one of their servers that they couldn't identify, but no evidence evidence that it was anything more than that.  To their credit, they disclosed that promptly & recommended folks change their master passwords just in case.

That day, may arrive sooner than most of us think.  Here is the historical record on life cycle of hash algo's.
http://valerieaurora.org/hash.html

Let us hope people see the day a long time ahead of time & upgrade the bitcoin protocol with plenty of time to spare.

A serious problem is, even taking delivery of your bitcoins from Mt Gox, won't really protect bitcoin holders from the possibility that Mt Gox has a problem.  Just look at what happened to the bitcoin market prices last summer.  

I think, even if its more expensive to do complete segregation of customer funds and 100% funding of all customer deposits (in whatever currency the customer has deposited as demand deposits at highly rated banks), for Mt Gox to take that step, would be a huge service both to themselves and to the bitcoin community.  

As an exchange, it's in Mt Gox's long term interest as it would enhance the sustainability of their business model--they have a vested interested that no one lose confidence in their exchange or in bitcoin in general (the latter two can't really be separated for now since Mt Gox has such a large share of the exchange market).

Short of that, a reputable CDS market for Mt Gox might help.  

Or if someone would step forward some day to form a clearinghouse for settlements that operates with separation of customer deposits and full disclosure, all the exchanges could start using it.

That sounds like a great idea, providing the java script webpage you create, is run in an environment where nothing is stored, such as a ubuntu live cd...