Solo-mining, I am only getting about 36% orphans, average, over the past 24 hours.

Remember, the POS allowance is based off the total generated coins, so with all the days of non-POS, there are a lot of holes to be filled. It should not take more than a few days to normalize.

If you want to help alleviate the issue, simply mine another coin, but keep this wallet open and unlocked, so you create all the POS you were denied. I don't mind the orphans, that just makes the price I have to ask for, higher.

Like I said, don't settle for less than 0.0005 BTC/CAP... And stay firm on your order. Buying the few short-sales listed for easy coins. (Easier than mining... If you mine another coin, and trade that for BTC to buy CAP... There are plenty of overvalued coins you can mine for a quick turn-around to coins of actual value. Leave them with the debt of holding an overpriced coin, while you consume the undervalued coins.)

Don't mine just to mine, mine so you have something to trade with, to get what you actually want.

Also the block-explorer is not correct, it is several thousand behind. 128927 is the height I get.

Any idea on when the new client will be released? The one with shorter block retargets...

I agree that per-block is a bit much, but "every EVEN block", with a 4-hour target-time... or "every 10th block" with an 8 hour target-time would be better than what it has now.

Note, since the target it 4-hours, you would not do a 100% retarget-level, you would only do 50% of the expected retarget. If it was too short, it would adjust closer the next time, and the next, and the next, until it hit the 4-hour expectation.

To determine 10th, is easy...
if int(Block-height/10)*10 == Block-height then adjust-diff
Eg...
Block-height: 223 [ int(223/10) = 22 * 10 = 220 != 223 ] No retarget
Block-height: 240 [ int(240/10) = 24 * 10 = 240 == 240 ] Retarget next block...

Could be done faster with bit-values of 8... with a simple mask or bit-shifting the block-height value.

But you get the idea.

Also, Try like hell to get this on any exchange again. (Other than the one listed, or having to depend on private deals.) That makes it easier for shops to accept coins as payments, unless you simply get more shops selling stuff that is normally free, using these coins as a bonus for other linked-sites, to more content. (Eg, convince them to give coins away to paying members, for use on other sites. Coins they got as payment for viewing content or coins they purchased from an exchange. Show them how simple it is to setup an exchange account, or set them up with one yourself, for a cut.)

This would make a great "contact me" payment, or "gift her/him" for an adult social site. (Like how OK-Cupid uses BTC.)

Mine faster...

This is why I believe POS should be a completely separate chain. No competition with POW that way. Valid coins just move from POW to POS, and back again, as a normal transaction, with no ability to "spend" the POS coins in the separate chain.

That, or simply have POS as a special "NOTE", with a 0.0tx, with the NOTE being the POS hash. (The only 0.0tx allowed by the system, with the following one being the actual POS transfer that gets returned to your wallet when it expires, but the accumulated total used for POS reward.)

Wow, instantly got 11 connections, without any "connect" hacks or even one addnode or peerlist...

This will be a fun next few days with all the POS blocks...

Raise your asking values, to adjust for losses of orphans... Don't settle for less than 0.0005 (at the least). Let those other guy sell for a loss, and swipe some of them up for yourself. Once the diff climbs back up, it will get back to 0.001 and higher.

There is about to be a big cashout on BTC, once it hits $150, or 20,000 BTC is available for $130/BTC avg. Those major ballers with the THs machines have been holding-out, because they just can't cash-out for less anymore, but they will cash-out.

It has also dropped, like all coins have, due to BTC rising in value. (Thus, it takes less coins to equal the same dollars for exchange.)

All coins still have a strong trade-tie to BTC, so they all do this. They do not all do it proportionally by value, or at once, but they all do it.

Simply stand your ground and don't settle for less, and take advantage of those crazy enough to sell for less, by buying them when they are listed low. They just saved you from having to mine them, to make money.

Also, the more coins there are to mine, for a better value, the less that it leaves any single coin to remain valuable. They don't understand that they are the reason the coins they earned never reach the value they mined them at, because they are hopping. Then they sell short and live with the losses, defeating the purpose of mining the coins in the first place. Again, their loss, not ours, if we swipe those cheap coins up.

If it worked better, it would be called hardware, not software...

It it was made by humans, the best you can expect is something that has human error...

Until we have error-free anything, made by something inhuman and without error itself, we will never have anything that does not have errors...

The best cars die, the best software is the source of most errors, the best opinion of "best" still does not imply perfection...

What was the question again? lol.

If you see a fork in the road, take it!

Everybody wants something and something-else... but no-one wants nothing and nothing-else.

By your definitions of broken, everything in my house is broken. Nothing works as expected. But it all works.

My computer crashes loading some webpages, my toaster doesn't cook evenly, my dog runs in circles, the AC only cools down to 78F in the summer, the cable TV digitally breaks-up once in a while, the car I drive only gets 23MPG instead of the 28MPG it said, oh and I paid for all those... How much did you pay the developers for the bottlecaps program?

If you are not mining it, (driving), then why are you here?

If you are not here to contribute or pay for development, then you have no right to make demands. Everyone knew the risk going in, and everyone still knows the risk. If you can't take 1 minute out of your day to hit "refresh" on a block-explorer and compare those numbers to your miners... then you should go mine litecoin or feathercoin... Oh wait, they have forks too... Forks that last weeks and months... Forks you avoid only because they don't have POS and the diffs are higher (thus collisions further apart), and new versions that force you to stop mining, download, install, restart... All the same things we have been saying all along. (Happens faster on fast-coins, and this is a fast-coin.)

If your issue is with an exchange... go to that exchanges forum, not the coins forum. That is like you going to the bank to complain about not getting your paycheck from your boss. You are in the wrong location for your resolution.

Your wallet doesn't have to be in sync to send or recieve, only to mine. (Or to send coins that were just recieved, which have not arrived into your wallet yet. Unless you send without using your wallet, then it doesn't matter. Your wallet is not proof of funds, the chain is. Your wallet is just the medium for mining, and to display your records of transactions, and make transactions.)

Ok, I am going back to helping those who are interested in "sticking it out", through this bump in the road. Instead of dealing with people who don't even mine it, and are obviously just trolling the forums. Your loss, not mine. The less you mine, the more I have for a reward.

I'll be happy to take any bottlecaps you feel that you no-longer need. Since you "don't drive this car", you might as well let someone who does drive it, take it for a spin around the block.

CAP: EsdKQdsvhcYBdK562mnr3ggoDD5ydJSjEn

Better yet... donate them to help some of those pools regain some losses, or the developers who are working on it. I donated, so I am sure you can too. (Provided you are sending coins that were earned on the correct chain.)

Correct, it is WORKING, but not fine... but broken is not "something that doesn't work fine".

And you are driving this brand of car... (Can't say much more than that, you said it all for me.)

I drive it too, and keep coming back to see that others stay running. The issues have already been addressed, and are being worked-on. You want to speed it up... Pay him.

No

If you were mining and not creating POS, then your wallet is not broken, and you are not the source of the "worsening" issue. Broken = does not work. If you came here to post that reply, you are trolling. So keep your personal biased  judgement about my factually unbiased judgement to yourself. Hypocrite.

It is ignorance (ignoring the issue and solution, for personal gain, at the cost of the others.)
It is stupidity (the opposite of smart, selfishly leaving it on, for personal gain, at the cost of the others.)
->
Related to "worsening" the issue. (Making it "worse", when it would otherwise not be "as bad".)


LOL, they forgot "broken back mountain" and "brokers" and "crashed" and... (Sarcasm for the stupidly published and poor definition crap they teach in schools. Webster was a moron. #10 would have sufficed, but they obviously like to fill white space to sell themselves as being smart, just making themselves look dumb in the process. I am guilty of that myself. I am a hypocrite too. We all are.)

The program functions, just not the way it was expected, on all machines. It does exactly what other coins do... it forks. It just doesn't recover WELL on ALL MACHINES. Some machines it does. No other form of the word "broken" applies to this coin, without also applying to all other coins that exist.

The chain is broken... that is called a fork. Every coin forks, a lot. Most forking happens fast and dies fast and fixes itself. These forks just have "issues" being fixed. Which is "worsened" by those still throwing POS blocks at the chains.

The coin is not broken... It is running fine. The wallets are "acting-up", making it "difficult", but it is not "impossible to mine", thus, not "broken".

The last 30 posts have given instructions to disable POS. The last versions have severed the older versions, thus, they have all seen the request to stop POS, and instructions how to do that... (Though, I agree POS should be disabled in the client, by the software, by default, until that part is resolved.)

At this point, it is ignorance or stupidity "worsening" the issue. The fault of the program formula has already been addressed, and solution is manual, at this point. Any fault now IS on the ones operating the wallets. (Related to that issue.)

Sorry, but if you were told your car has a recall for failing brakes at 65MPH, and you refuse to drive under 65MPH until you can have it repaired for free... It is your own fault if you die in a crash because your brakes failed at 70MPH. By default, brakes work, but you don't have to drive the car. That is your choice, thus, your fault. (Not directing that to you... unless you are driving!)

You would think that is how it operates... but it does not. You have to have a lot of connections... that are also "getting blocks from" that tall chain.

We all see it... we all know it is 43 blocks behind... but our wallets never sync with that chain, because we, and the connections we have, have been severed... and/or we can not "repair" the incorrect blocks, correcting them with the correct blocks from the taller chain.

Lack of connections just makes that happen faster. (The clients have issues with connections.)

Your block-crawler has been able to stay 90% on track, and you fix it fast... so thus... it is mostly on the tallest chain. That is our only resource for block-height, except our wallets or the forums. (The forums just are not fast enough to check block-height. By the time you read a post, there could be 20+ more blocks, or 200+ more. As opposed to hitting refresh on your website, or seeing "out of sync" and "45 blocks remaining" in our wallets, which never catches-up, no matter how many connections we have, or how many times we reconnect.)

I still can't get more than 13-14 connections, using the "connect" hack/trick. (But, most wallets are like that, for me. I should find-out which ones are not like that, and that might give some insight to the issue that they can't seem to locate. Obviously the coin they are using for cloning has not resolved that issue either. Seems specific to home-users of various windows versions.)

However, it should take only 2 connections to stay up to date, with one roaming one, looking for taller chains. It shouldn't take 10+ connections if we are all doing the same thing, and have the same info.

The issue is this... in time... all connections end-up doing this...

(Group A: height 80000) A,B,C,D,E,F,G,H,I {9 connections} -> Was 18 conn (Half accepted N block, half didn't, taking D block instead.)
(Group B: height 80002) J,K,L,M,N,O,P,Q,R {9 connections} -> (Built off N block, rejecting D block, severed so can't send height to the other half now.)

Then S comes online... S sees us and them... so S joins the N chain (Group B), and tells the D chain (Group A) of the new height. It attempts to send the blocks, which the wallets just can't use to fix the chain, so they keep mining on the chain that they can mine on, the short one. (Never fixing the incorrect height by removing the incorrect orphaned blocks, rebuilding to the taller height.)

Then, that chain eventually fades, as new people and those noticing the issue, fix it manually and join the (Group B), which is now 20 blocks over (Group A). However, some of those connections are getting rejected, because they "are misbehaving", and that keeps the fork alive, instead of them stopping mining on the short fork, the program continues on a fork it knows is not correct. Until they are left alone and no work arrives for them.

Those previously mining the wrong chain, who still have rejection, and who still have those peers to join... keep getting back on the wrong chain. Because they just don't get the other block heights, until S comes online, and S is not rejecting them, because it just got online, and has not rejected them yet. Acting as a thin link... thus, leaving you with 10 connections, but only 1 link to the other chain, through S... if S gets severed, you lose it again... Even with the 10 connections.

Some clients just keep losing connections, plus POS is still being generated, causing forks. The clients/wallets are not correctly navigating back to a chain, once the fork happens. They just stay forked. Which-ever one you find first is the one you remain "stuck" on.

That is being addressed, for the next version.

Until then, the block-crawler is the first sign, along with your own wallet and miners, to determine if you manually have to hop-chains.

Indication of a fork...
- Diff lower than expected
- Reduced connections, less than normal
- Block-crawler height being higher. (If the block-crawler is lower... do not change anything, it will crawl to your taller chain.)
- Miner disconnection complaining about "Not enough work".

Apparently, more people are turning on POS, and screwing it up faster than normal. (Newcomers, or blind-miners, or idiots wanting that 0.0001 gain which costs them 100's in losses from becoming forked, mining orphans. If they ever repair their wallets, they will see they lost a lot more than they THINK they are making.)

Make sure you have the line...

reservebalance=100000000

Inside of your config... If you are generating POS (Which can be done before the chain finishes syncing.) They may be cutting your connection because you are attempting to submit POS work while downloading, and you are getting severed from that issue, which is not fixed yet.

Just restart the client/wallet... don't keep deleting the database. The other clients are cutting you off, from data delivery or the data is getting corrupted from one packet (Thus, stopping that block from being added to the database). Restarting will cause it to drop that packet and continue from where it got the last good packet delivered.

Once you are sure you are at the correct height, stop the wallet/client, and backup everything except "peers.dat", "wallet.dat" and your config file. (You can optionally backup your wallet to another location, but don't restore it when you restore the database. Wallet backups should only be restored if you are in dire trouble, and your wallet somehow gets corrupted or damaged.)

Use those other files to restore the database if you "fall off the tall chain"... Because the wallet does not seem to have the ability to "fix" or rebuild the taller chain after you have gotten blocks from the shorter chain. (If it can, it does not do it within a reasonable time. I waited hours and it never fixed itself, though it could see the taller chain and see I was not synched.)

And the wallet doesn't seem to "archive" the "known good database", for easy restoring from that point forward.

Also try the connect thing a few posts up... using the list of connections from the block-crawler list of connections.

Another wierd thing I noticed...

When the application froze, after trying to shut it down to delete the bad chain, and restore a known good backup, for rebuilding the correct chain... (Because, again, it saw the correct height, it just didn't do anything to "fix" the chain itself at that point. Rebuilding from the split, as one would assume it would do.)...

I had to go to taskmanager, which is not abnormal for the last 1.4.1 and 1.4.2 builds... and kill the app. However, there were three bottlecap-qt.exe's running in the taskmanager. There were not 3 when it was running normally. But I can not confirm if "trying to exit normally", caused the three instances... or if somehow while running, and losing connections...that 2 more instances just launched themselves? It was strange. (I will wait until it gets to that point again, and make some observations. However, I suspect that the "exit" function is screwy, causing the app to attempt to relaunch, in order to close itself or finish closing work, and just hanging in the process.)

The best luck I have had, staying on the right chain is by doing this...

EDIT: (Also, using reservebalance=100000000 to stop POS from happening by my wallet.)

Took the list of connections from the block-crawler and changed 8 of the "addnode" to "connect". That gave me more than the normal 8 connections that I would seem to be limited to, if I just had all "addnode" links. Giving a total of 13-14 connections, as opposed to 8.

EG...
I turn this list... (Which normally only give me 8 connections.)
maxconnections=100
addnode=92.5.104.42
addnode=108.20.60.26
addnode=192.241.222.16
addnode=192.241.216.151
addnode=192.241.222.102
addnode=192.95.37.194
addnode=24.5.121.137
addnode=188.165.211.202
addnode=88.100.132.85
addnode=70.79.24.157
addnode=80.198.94.98
addnode=217.169.211.146
addnode=69.9.152.126
addnode=69.10.44.115
addnode=67.11.24.42
addnode=192.64.86.238
addnode=72.238.120.59
addnode=50.137.233.14

Into this... (Which gives me 13-14 connections.)
maxconnections=100
connect=92.5.104.42
connect=108.20.60.26
connect=192.241.222.16
connect=192.241.216.151
connect=192.241.222.102
connect=192.95.37.194
connect=24.5.121.137
connect=188.165.211.202
addnode=88.100.132.85
addnode=70.79.24.157
addnode=80.198.94.98
addnode=217.169.211.146
addnode=69.9.152.126
addnode=69.10.44.115
addnode=67.11.24.42
addnode=192.64.86.238
addnode=72.238.120.59
addnode=50.137.233.14

That is the only solution I have to those showing low connections. This trick should also work if you have high connections, and you should now see more than what you would see, if you only had "addnode" for your connection types.

However, even the "connects", eventually kill the connection, and I get left with only "addnode" links, which thus returns to 8 or less. At the time I noticed that the chain was not matching, I only had 6 connections left. Which took almost three days to happen.

Now, I started again with 13-14 connections, using the same trick above... But 12 hours later, I am down to 11 connections. So, I assume I have the 8 addnodes and lost 2-3 of the ones I forced to connect. They either left, changed IP's, disconnected from me for ??, decided to link another wallet instead of me, or are now mining on a private chain/fork...

So connections are still being rejected, for no apparent reason, causing the issues. Having more connections only delays what happens, and when it happens. The result is still the same. The constant severing of connections leads to isolation at some point, when the cross-thread-IP connections can no longer communicate with the largest hash-rate miners. (Those are the ones that eventually become the tallest chain, because they just find blocks faster than total of severed units that are still joined.)

Forked again... 180 blocks behind on one fork...

Some people are still running with POS blocks, still screwing-up the chains.

Funny thing for me... I was introduced to bitcoins (had known about them before), by a friend who I was planning a minor gold-mining expedition with. I took a second look at the coins, and honestly didn't know the details of it, but my gut said stay away. Major red flags, and lack of info at the time... (Went with silver instead... Which was just as wise a choice. More reliable and better possibility of an actual return, which it did give a return on.)

One year later it went from about $14/BTC to $250/BTC, and I was kicking myself in the ass for telling him, and myself not to get involved in it.

To not miss the boat again, I jumped in, but not fast enough. Spent about $4000 on equipment, made about 25% back before BTC just wasn't worth mining, a month later when all the ASIC's started pouring-in.

Now I happily mine a long list of alt-coins. Making roughly 300-500% more than if I were mining BTC. (Mining and trading.) Sadly watching as BTC lowers in value, per hash, making everyone less money, except those few with major machines. Essentially blowing the majority of initial investors out onto the streets.

Now the streets are littered with tons of other options that mine with more reward. Even with all the variety and redistributed miners, they are quickly smothering BTC, faster than the greedy few ASIC miners in the ASIC war for our money. In the end, they will have all the coins and can trade them with themselves. We will continue to use alt-coins, since we are the majority with the majority of the money they want.

My life in BTC was short and uneventful and a waste of time. Once I hit my ROI, I will be investing in a more realistic and less sloppy transaction processor that doesn't kill GPU's and waste my time processing nothing for nearly nothing, when a simple lotto would have sufficed for these types of coins. So much bulk, overhead, over-complexity, and short-sightedness in design. But for most here, it is all they know, and they just accept what it does, as being acceptable. So sad.

Sea-shells reinvented as digital rape. Funny part is, you are doing the banks work, for essentially free, at your own costs. Except you are doing it 10,000-times more inefficiently. The ones making all the real money are the electric companies, your ISP's, the exchanges, paypal, credit-cards, banks, governments through legalities, and those using you to launder transactions for free. Everyone but the actual miners.

The hype is gone, the reality still sucks, and the rewards are reserved for only a few. (Rewards created by making others loose, as opposed to rewards created from anything other than theft and loss... like substance or actual payment for doing something... anything... other than finding a lotto-ticket. You can't win if you don't play... Well, you can't lose either, if you don't play. There are more losers than winners. Doesn't take a genius to figure that out... only stubborn hope to ignore the obvious.)

One thing to remember is that delays in multiple communications, coming through TCP are horrible... That is why FPS shooters don't use TCP. There is no guarantee of time-delivery. Sent-time is never equal to delivered-time, off by many seconds at times. That is in addition to the layers of stacked TCP delays...

EG, Delivery path sample... "->" = TCP delivery delay of 500ms to 4500ms (0.5sec to 4.5sec) each.
My miner solution when it finally finishes the worksize -> My wallet -> My wallet checking -> IRC room I connect to USA,FL -> IRC relay node USA,NY -> IRC relay node EUR,Fr -> IRC relay node CHN,Sh -> Your wallet JAP,To -> Your wallet checking -> Your miner when it finishes its current worksize that it has to dump, before it can begin working on your own solution to the next block.

** Assumed processing time to be equal to a hop... with local-paths. (Wallet->miner through loop-back or home net router.)
Total time: 9 * 500ms = 4.5sec to 9 * 4500ms = 40.5sec (Worst perfect world case "time-out". Up to minutes in reality, but rare.)

That same path as UPD delivery would be 50ms to 1200ms... (Again, assuming the 20ms loopback but including processing time there.)
Total time: 9 * 50ms = 0.45sec to 9 * 1200ms = 10.8sec (In a perfect world UDP expire time.)

Thus, higher diffs to allow time for them to traverse the net faster. (Faster as opposed to flooding, which causes further delays and out-of-order sequence delivery. Thus, less TCP "resends" of broken or undeliverable packets.)

Another thing you could "try", is using the last value of a persons wallet ID (The private key pair value), to determine when that wallet can submit and start looking for a POS solution, when a POS solution is desired. EG, if the last 8 bytes of our key-pair are used to determine this... that is 256 possible submit/start times per 5 minutes... 5*60=300 seconds... 300/256 = 1.171875seconds per byte-value... Assume it it midnight 00:00:00, and my value is 256... I can't find a solution for POS until 00:05, because it is not my time to find a solution, but after 00:00:05, it is my time, and one is still desired by the system... I begin... Now I find one, and it is 00:00:12, I have to wait until 00:00:15 (My next available submit time that I am allowed, otherwise the network will reject it.) It could be submitted before that time, but the network would not accept it until that time. First-come first serve... But by that time, everyone already has it, to begin working off of it, if it was submitted early, had time to distribute, and was still valid. (Eg, another block was not found in that time, that was also valid. Which would leave 254/256th of the network not looking for POS for the next 1.171875 seconds, and 5 minutes before the 1/256th of the network similar to my ID, would send again, at the least.)

Something like that, or...

Force clients to STOP submitting a POW at every 5 minute-mark, while the network waits for 1 POS to be created and submitted, failing after 2 minutes if none are submitted, continuing with POW acceptance/delivery. First valid POS to have the most confirms over the others, wins... (Again, the above could alleviate losses there. Only those available to submit this round, can submit.) You could stall the POW by making the DIFF +0.5 of the normal expected diff for that block, just prior to the time when a POS is expected... or whatever is needed for a diff adjustment for that block to make it a 3-min target, instead of a 1-min target.

Eg, POS "valid if" and expected at times xx:00:xx, xx:05:xx, xx:10:xx, xx:15:xx... thus actual hour does not matter, and seconds don't matter for validity. Just the minute mark.

Might also help if you shot for a 1.5min target for normal blocks. I believe it is 1 minute targets now, which often gives a 30-45 second block-time result, due to luck of the lotto-draw with multiple machines, on average. (That is what my cgminer shows.) EG, 1 min time... Luck of the lotto... we all have to loose the lotto (bad luck) to find no block within 1 min target. Only one of the thousands has to win, to find that winner within less than 1 minute, and there are a lot of winners within a minute of time. Even with auto-adjusted per-block diffs, which could be every even block, adjusted if per-block is too much variation to contend with.

Any ETA for cryptsy yet? I don't think there was any significant branches in the last 24 hours... (At-least none that I was on the wrong side of, or that was posted here. Other than the mini-fork that one night.)

I am anxious to buy more. (Without having to create another account at another exchange.)

Just curious if anyone heard anything...

Actually that's radioactive... (Sort-of)

Might want to make the arrows matching the wallet icons, the curved ones... For the top icons. (Just my 2-cents. It would be easier to follow. More standardized/themed.)

Yea, those floating point values are no good for anything other than 3D and generalization. (No possible way to fix them, due to them being pre-calculated from LUTs in the CPUs and backed by LUTs in the OS's, which all have variations and quirks.)

Decimal and "format" or Currency is more reliable, unless you really need 13 decimals of sort-of precision. (I believe true 64-bit linux and OSX may use native double-double, converted to double, which is not the same as just a double answer.)

It's always math that screws us in the end...

Where possible, you get faster results if you do the multiple instead of the screwed-up division, where possible. EG, replace all /2 with *0.5, all /4 with *0.25, etc... or even x*(1/2) is faster than x/2, because the LUT for 1 is the largest and fastest, and the multiply function is 10,000x faster than division of a variable value, then the LUT of the fixed values. (Constants help there too. Acts like a custom LUT for you. Using div_2 = 0.5, div_3 =0.3333333333333333, div_4 = 0.25, etc... Then all your answers are the same on every machine. 100% Then you use them like this... if X * div_3 >= Y then...) {LUT = Look-up-table}

I like the sounds of the mentioned plan of attack for the updates. Sounds like some logically wise choices. However, for a future update, I would still like to see the suggestion of the DB separated into two parts. The archive of blocks, relevant to the last hard-coded block, which never has to be deleted, and only gets updated when the program becomes updated. And the separate self-repairing "new blocks", that would be the only portion we would have to delete, in the event of failure to self-repair when trying to connect to a larger block-height. Since the programs seem to choke and keep us mining on the wrong chain.

Actually, we only need the last tallest block to mine on the correct chain. The database can be fixed at a leisure, if it just got the last block hash of the tallest chain that others have already confirmed as valid. Might want to look into that idea first.

EG, I have block 85000 but the tallest chain that 3 more have confirmed was block 85150... Just give me that block, and let me build off that. WHEN the wallet fixes itself, now that it knows it is forked, it will end-up showing my block that I found 85151... eventually... as opposed to keeping us mining on the smaller chain, mining block 85001, which it KNOWS will be an orphan anyways.

That would put your wallet/system above and beyond what any other wallet/system offers...