Quote from: LoyceV on January 20, 2018, 11:08:37 AM

After reading the entire thread, I wonder if there is any specific reason to use 32-bit software on a 64-bit OS. I doubt it's related, but it seems to be an unnecessary limitation.

At this point, I run all qt based wallets from external USB drive(s). Each crypto-coin gets a unique hard drive. (Litecoin, Original Bitcoin, Bitcoin Cash, etc) For backup, I mirror each drive into a single compressed bundle. Use of 32-bit versions allows me to attach external drive to any system in the building. CPU hardware doesn't really matter, version of Windows OS doesn't really matter. Typical data corruption event only disables one type of coin. Recovery of an entire wallet and database from bundle takes a couple of hours. Process to create stand-alone qt wallet on external USB drive is a little tricky, but is well worth the effort (IMHO).

That being said...

I'm doubting that open source wallets will be fixed any time soon. Remaining bugs are subtle...typically stem from conceptual/architectural errors. Original developers/coders cannot "see" the problems, because they are reviewing their own work. Must reliably reproduce the failure in order to identify and isolate the malfunctioning code. With involvement of asynchronous components...sometimes from sources external to code-running systems...fault reproduction may require very expensive test & measurement equipment, and/or hundreds of person-hours of tedious and frustrating bug hunting. Most open source developers cannot expend this quantity of resources. Thus last 2% of bugs inherently require "big corporation" resources if a timely solution is to be found.

Do serious, show-stopping bugs, still exist in mature software? Undoubtedly. Really bad bugs only emerge during "perfect storm" situations. Also known as "black swan" events.

Here is a classic conceptual problem (below). Unrelated to this thread, but instructional/educational nonetheless. Portions of "Project Web" on sourceforge is/are down. Database migration is in progress. Applications that check with SF for version update/release BEFORE opening control panel are all broken. This is worldwide, most likely. Apps cannot fetch version numbers, because SF is down. End users cannot easily disable version/update check, because control panel will not open. Tsk. From my perspective, this bug should be fixed within application code...even though the application itself is not to blame.

>
> Exception in thread "AWT-EventQueue-0" java.lang.NumberFormatException: For input string: "Project web is currently offline pending the final migration of its data to our new datacenter"
> at java.lang.NumberFormatException.forInputString(Unknown Source)
> at java.lang.Integer.parseInt(Unknown Source)
> at java.lang.Integer.valueOf(Unknown Source)
> at me.mabra.hellonzb.HelloNzbToolkit.getVersionParts(Unknown Source)
> at me.mabra.hellonzb.HelloNzbToolkit.isLatestNewer(Unknown Source)
> at me.mabra.hellonzb.HelloNzbToolkit.isUpdateAvailable(Unknown Source)
> at me.mabra.hellonzb.HelloNzb.checkProgramUpdate(Unknown Source)
> at me.mabra.hellonzb.HelloNzb.(Unknown Source)
> at me.mabra.hellonzb.HelloNzb$1.run(Unknown Source)
> at java.awt.event.InvocationEvent.dispatch(Unknown Source)
> at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
> at java.awt.EventQueue.access$500(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.awt.EventQueue$3.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
>