[ANN] GameCoin (GME) - Current version = v0.8.4.2

[usahero]

No, block reward after 64k block is 400 in all cases. Last block I received 1000 GME was before 64k.

[1714307594]

1714307594

[1714307594]

1714307594

[ahmed_bodi]

After block 64k, difficulty dropped and no increase of difficulty since then. Looks like there is some bug in the new version.

No as I pointed out there was a fast block injection well before block 64k, I assume an attack as there was no payout address on the mined blocks. You can see after block 64k that most of the blocks were still paying out 1,000 coins meaning is was an old or hacked client.

I would say that block 63485 onward was a forked chain and we need another checkpoint release if it doesn't correct itself. I certainly wouldn't be doing any transactions.

correct it was near that point where my pool with the majority hashpower switched off the network onto its own fork since i wasnt around to update, so technically we are now on what we would like to call the proper chain

[erk]

No, block reward after 64k block is 400 in all cases. Last block I received 1000 GME was before 64k.

You better have another look  http://gme.p2pool.nl/chain/Gamecoins

[elend]

No, block reward after 64k block is 400 in all cases. Last block I received 1000 GME was before 64k.

You better have another look  http://gme.p2pool.nl/chain/Gamecoins

an official announcement on the 2GMTA-Website says: all block explorers of the 2GMTA pools are disabled currently due to instability

therefore the block-chain you pointed to maybe not correct....

[Sondey10mg]

I'm on the blockchain of the explorer. payouts still  1000GME and very low diff.


How to fix these forks??

[Sondey10mg]

Btw, I'm obviously not the only one mining this chain. Only 1 out of the 10 blocks is mine

[usahero]

No, block reward after 64k block is 400 in all cases. Last block I received 1000 GME was before 64k.

You better have another look  http://gme.p2pool.nl/chain/Gamecoins

This is not the blockchain I was talking about.



I was talking about this blockchain. After 64k block on this chain, the block reward was 400. The blockchain you provided has all blocks after 64k with reward 1000.


15:01:02

{
"blocks" : 78936,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00024414,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkhashps" : 777111,
"pooledtx" : 0,
"testnet" : false
}

Or "this" blockchain:

Windows - QT wallet

shakezula has kindly compiled a Windows QT wallet and you can download it here. (Select File --> Download from the menu or press Ctrl+S)

[Petr1fied]

Everyone should really stop mining and allow me time to look into it. There is clearly something wrong with the code in v0.8.3.1 which caused the difficulty to just continue dropping until it hit the absolute minimum regardless of the amount of hashing power that was thrown at it.

One thing is for sure I'm going to have to roll back the code to the state it was in v0.8.2.1 at the very minimum which means that anything mined from block 64,000 onwards with v0.8.3.1 will become an orphaned block. At least the difficulty is actually increasing on the v0.8.2.1 fork.

[Sondey10mg]

Everyone should really stop mining and allow me time to look into it. There is something clearly wrong with the code in v0.8.3.1 which caused the difficulty to just continue dropping until it hit the absolute minimum regardless of the amount of hashing power that was thrown at it.

One thing is for sure I'm going to have to roll back the code to the state it was in v0.8.2.1 at the very minimum which means that anything mined from block 64,000 onwards with v0.8.3.1 will become an orphaned block. At least the difficulty is increasing on the other fork.

good call. 10000+ blocks or 15-20% of the whole blockchain mined in a few days is not healthy

[usahero]

More like 15k blocks in 6 hours

[Sondey10mg]

More like 15k blocks in 6 hours

Even worse 

Sucks for the few who've been mining on the correct chain, but reversing to block 64000 is needed if we ever want to see this coin traded again.

[ahmed_bodi]

right okay. my pool is currently up to block 61.5k after a lot of manual labour when we hit 64k i shall kill the pool for everything apart from withdrawals. I will have another pool up for GME soon which will be prop until the fork issues are solved and then back to PPS, expect a nice pump to the prices too since ill have to buy up quite a lot for PPS

[bluestang]

My wallet crashed when I opened and tried to sync. with a Microsoft C+ error before bluescreening if that helps ya at all.

[elend]

My wallet crashed when I opened and tried to sync. with a Microsoft C+ error before bluescreening if that helps ya at all.

which version do you speak about ?

I had a simmilar problem with 8.2.1 and therefore jumped from 8.1 to 8.3.1

[bluestang]

My wallet crashed when I opened and tried to sync. with a Microsoft C+ error before bluescreening if that helps ya at all.

which version do you speak about ?

I had a simmilar problem with 8.2.1 and therefore jumped from 8.1 to 8.3.1

0.8.3.1

Opened it up this morning and started to sync, then bammo...crash to BSOD.

[erk]

The point everyone seems to miss is the problem started at block 63485 not block 64000, prior to block 63485 blocks were being found every couple of minutes, then they suddenly were coming in every few seconds, I was watching the count on one of the pools stats pages, not on the block explorer that came later. Someone started to inject fast blocks at block 63485. Then when we hit 64k some of the blocks were 400 coins long but most were still 1000 coins. I would say the 400 coin long blocks were the legit ones, and the 1,000 were an attack or bad cleint.


A fundamental flaw in all the crypto coins bases on Bitcoin code, is the ability to accept mined blocks at a faster rate than a per-determined lower limit. eg. if you want your block rate to be 60sec then peers should not accept blocks that are time stamped ad being mined less than 30sec apart. The client software should use the  many time servers on the Internet to set the time accurately, then reject impossible time stamps such as pre-mined chains from an attacker.

IRC peers should be disabled by default in the client software, and a few reliable seed nodes in the code.

I good coin should use NTP timestamps not timestamps agreed by the coin network. The problem is discussed here:


http://culubas.blogspot.com.au/2011/05/timejacking-bitcoin_802.html

[elend]

The point everyone seems to miss is the problem started at block 63485 not block 64000, prior to block 63485 blocks were being found every couple of minutes, then they suddenly were coming in every few seconds, I was watching the count on one of the pools stats pages, not on the block explorer that came later. Someone started to inject fast blocks at block 63485. Then when we hit 64k some of the blocks were 400 coins long but most were still 1000 coins. I would say the 400 coin long blocks were the legit ones, and the 1,000 were an attack or bad cleint.


A fundamental flaw in all the crypto coins bases on Bitcoin code, is the ability to accept mined blocks at a faster rate than a per-determined lower limit. eg. if you want your block rate to be 60sec then peers should not accept blocks that are time stamped ad being mined less than 30sec apart. The client software should use the  many time servers on the Internet to set the time accurately, then reject impossible time stamps such as pre-mined chains from an attacker.

IRC peers should be disabled by default in the client software, and a few reliable seed nodes in the code.

Well you mention a couple of fundamental issues concerning the most cryptocoins.

Solving this issues can be adresses on a more long-term timeframe.

In my opinion they are not the reason for the actual problem of Gamecoin.

Actually - I think - there is just a bug in the Gamecoin-Code starting with version 0.8.2.1.
Especially concerning a correct difficulty-upswing.

As Petr1fied told us earlier, he/she is already looking into the code an searching for the bug.



 

[Petr1fied]

I don't believe the issue existed in v0.8.2.1, I believe It was introduced in v0.8.3.1.

The fairest solution to all is to roll back to the last block that all clients will have accepted which was 63,999. At this point I intend to create a separate fork by mining exactly 1 block. This new block 64,000 will be added as a checkpoint and this is where we will be starting from in the next client version.

I have abandoned the plan to reduce the block time from 2.5 minutes but I'm not going to increase it either. I will however be bringing retargets to 12 blocks apart and I intend to make the maximum adjustment 110% although it will remain on 400% for the first few retargets to bring us up to around a ~0.25 difficulty by block 64056.

The next client version will also ban all versions lower than itself from the get go so the update will be as mandatory is it can possibly get.

I am currently running isolated tests from my new baseline block 64,000 to ensure that it is behaving as expected so don't expect a new release too fast. I'd much rather fix issues now than have to do all this again.

[erk]

I don't believe the issue existed in v0.8.2.1, I believe It was introduced in v0.8.3.1.

The fairest solution to all is to roll back to the last block that all clients will have accepted which was 63,999. At this point I intend to create a separate fork by mining exactly 1 block. This new block 64,000 will be added as a checkpoint and this is where we will be starting from in the next client version.

I have abandoned the plan to reduce the block time from 2.5 minutes but I'm not going to increase it either. I will however be bringing retargets to 12 blocks apart and I intend to make the maximum adjustment 110% although it will remain on 400% for the first few retargets to bring us up to around a ~0.25 difficulty by block 64056.

The next client version will also ban all versions lower than itself from the get go so the update will be as mandatory is it can possibly get.

I am currently running isolated tests from my new baseline block 64,000 to ensure that it is behaving as expected so don't expect a new release too fast. I'd much rather fix issues now than have to do all this again.

I am amazed, how many time in this thread do I have to say the attack started at block 63485 can't you people simply look at the block chain at that point and the timestamps to confirm what I am saying? You are proposing to validate the bad blocks between 63485 and 64000 by introducing a checkpoint I don't believe this nonsense!

[Petr1fied]

I've not examined every single block but I've only noticed 1 block which appears to go back in time by a matter of a few seconds, we're not talking hours here as would be expected if someone just dumped blocks on the network. All of the rest appear to go in sequence albeit getting generated ever faster due to the rapidly dropping difficulty.

There is an error in the code which allowed it to go to the absolute bare minimum difficulty and stay there. I have confirmed as much myself in testing. That is what has caused the massive number of blocks so yes I am going to validate the blocks up to 63,999 as this is the point that all clients agree on before going their separate ways.