Another bug, mentioned
earlier, still occurs:
after running the wallet for a while (hours) the "Synchronizing with network.." progress bar reappears saying:
327431 blocks remaining
and when hovering over it with the mouse:
Downloaded block 46579 of 374010
although there are only 46579 blocks in total by now.
Errors like the following show up in the -printtoconsole log:
ERROR: FetchInputs() : 7f86e710b0 mempool Tx prev not found 73a5af9661
stored orphan tx 7f86e710b0 (mapsz 15)
ERROR: FetchInputs() : d02d4ba85b mempool Tx prev not found 8ca4687af1
stored orphan tx d02d4ba85b (mapsz 16)
received getdata for: tx de72b672826e9013aa7f
ResendWalletTransactions()
ERROR: FetchInputs() : 38b44facd9 mempool Tx prev not found c39f7dc03d
stored orphan tx 38b44facd9 (mapsz 17)
Not really a bug, just one or more people who are trying to get us on the LTC (or another) chain.
Just ignore it
Oh
Weird. How do they do it?
Not sure *how* they do it ... probably a misconfigured port somewhere.
But normally this should not happen because litecoin clients should not be allowed to talk to phenixcoin clients.
Each coin should use a different identifier (often called "magic number"), but pxc and most other coins did not change this identifier when copying the code base of litecoin
(this identifier is 4 bytes, in the pchMessageStart variable)
With a correct setting of this variable to something else (as long as it is not used by another coin), it would take at least someone manually copying the litecoin blockchain into pxc directory to have this problem.
Thanks, that's odd indeed, I mean what are the odds for that working? Shouldn't the proof of work system reject locally invalid blocks from a different chain and prevent this? Well, they managed to trick my client somehow