Hello All,
I have investigated the matter further and identified the cause of this issue and came to the conclusion that the Blockchain magic of KarmaCoin Here:
At Line :
https://github.com/karmateam/karma/blob/master-0.8/src/main.cpp#L3298// The message start string is designed to be unlikely to occur in normal data.
// The characters are rarely used upper ASCII, not valid as UTF-8, and produce
// a large 4-byte int at any alignment.
unsigned char pchMessageStart[4] = { 0xfb, 0xc0, 0xb6, 0xdb }; // Karma: increase each by adding 2 to bitcoin's value.
To correct this problem would require a hardfork and the community will need to agree on that.
Warm Regards,
~SoopY~ hardfork and move on ...
get it back on track ...
#crysx
yup , everyone will need to agree on this.
I am not convinced that a hard fork is necessary.. as stated in the post above, those magic bytes appear in many many other coins so if it was that serious a problem then ALL of those other coins will also be experiencing it.
From what I understand of the problem some people are experiencing a situation where there wallet is attempting to connect to nodes from other coins.. the majority (people who keep their wallets peers.dat file updated) do not appear to have this problem
As a software developer with more than 12 years solid commercial experience I can tell you that making fundamental changes to a piece of software forcing EVERYONE to either update or be locked out of the network (i.e. a Hardfork) is the absolute last resort option. Just imagine if windows and android operating systems forced users to update their entire operating system to the latest version and shut off connection the internet to anyone who did not update, every time they found a security flaw.. that is essentially what a hard fork is.
What I would like to know is that since the default port number for each coin is different such that very few coins actually share the same port number, then how and why is it possible for peers to be showing up from other coin networks?
Surely we should be looking at how this is possible and how we can prevent it from happening.
for example.. is there some code we could add to the peer handling mechanism which would only accept peers that connect via the valid port numbers and reject all others?.
You should not be able to "Addnode" peers with invalid port numbers for example.
And also regarding the suggestion from others about hard forking to hard code seed nodes.. not a very good idea.. since seed nodes come and go over time you will inevitably end up with hard coded seed node links that are broken. Of course nothing is stopping people from compiling their own wallets with additional seed nodes (this does not require a had fork).. and of course nothing is stopping people from simply using a peers.dat file which has update peer information already contained within.
the last time this coin hard forked we became bombarded with complaints from people who had not updated their wallets and were either looking for missing coins or had been mining on the wrong fork for many weeks and lost their newly mined coins as a result.
therefore I will not support any hard fork unless I can be convinced that there is a fatal flaw in the software which cannot be fixed by any other method than a hard fork and I am also convinced that the relevant testing is done on the test-net before switching over to the main network.
let me just remind you all that those magic bytes have been with the coin since day one.. and the coin network has been running successful since day one.
...
