Well, this sucks.
~/.florincoin# grep "Invalid but confirmed transation found:" debug.log | sort | uniq | wc -l
10261
There are 10,000 confirmed transactions in the blockchain that do not validate in the new codebase.
Out of 2,086,758 total transactions that's only a half of one percent however they all seem to be in the recent blocks. The first one was in block 1,505,023 the most recent was just a couple blocks ago.
I'm pretty sure this is due to OpenSSl updating and changing how it handles signatures
In July OpenSSL released a new update which caused compatability issues with previous versions and forked the bitcoin blockchain
http://cointelegraph.com/news/miners-lost-over-50000-from-the-bitcoin-hardfork-last-weekendAfter the OpenSSL update florincoin had no updates until December 10th when a new checkpoint was added.
https://github.com/florincoin/florincoin/commit/28443da787504436066d391e0d5e75054f8627d2The first invalid transaction appears in block 1,505,023, on December 10th.
http://florincoin.info/explorer/tx/?txid=6cba295dbd61a81c35ab994a94b6e758782661b976ee015043ea2314f84535bfSince that point they've been scattered throughout various blocks.
From the looks of things when the new version of florincoin was compiled on December 10th it used the newest OpenSSL at the time which caused these new signatures to start appearing, whereas bitcoin/litecoin use libsecp256k1 for their signatures to maintain compatibility but florin waited a bit "too" long and is already filled with "invalid" signatures from libsecp256k1's perspective.
I'm not sure what the best means to move forward now is. My initial thought was if it were only a couple transactions I'd whitelist them to bypass verification but there are 10,000 of them so that seems a little ridiculous. My second thought was to bypass verification on these transactions if they were included in a block prior to the latest checkpoint, along with a newly released checkpoint however that was shot down with the idea that these transactions are still occurring fairly regularly unless we had a sort of instant fork to get around that but I don't know if that's reasonable. From my understanding bitcoin remedied this by advancing to block v3 and rejecting these invalid transactions, which at the time for them was only a couple block fork that was reworked and orphaned unlike the 300k blocks since December we are dealing with here.
One idea I haven't ruled out yet is to set a block such as 1,600,000 which is a ways out to transfer to block v2 and start rejecting v1's thereby forcing everyone to update to libsecp256k1 instead of openssl, the remaining issue being what to do with the blocks and transactions between now and "then".
Next idea is to just YOLO it and make an announcement then update instantly with a checkpoint to force the right side of the fork, with coordination from pool operators to ease the pain. Sort of like just ripping the band-aid off and getting it over.
Again, I'm not entirely sure the best course of action moving forward. Prior to a few days ago I knew nothing of florin so I don't know all of the details, are there many pools or solo miners? How hard would it be to pull off a YOLO update which blindly trusted any transaction prior to the new checkpoint and then began rejecting all v1 blocks from old nodes after the update?
----
Next point, I've only dealt with the linux daemon, I have not gotten into qt nor windows binaries yet. Although so long as the daemon is running properly it should be "easy" to get qt and windows going as well.
----
If any of my post doesn't make sense... well... I'm tired and it probably doesn't make sense.
