[GLC] Globalcoin | 4 Year Anniversary 1.5.4! | NO IPO, NO PREMINE | [SCRYPT]

[allknowingeye]

I think it's been known for some time that the code is not the greatest. It was given the boot off at least one large pool because of code issues. I myself have had trouble creating transactions larger than 400 coins - they simply fail. It seems to have a very small block size for transactions. It needs a lot of work and in the state it's in whether that is worth the effort or not is questionable. About all it has going for it is 3 exchanges carrying it for the moment.

Seems to me the problem relates back to the node 216.177.81.87 hanging on to this second chain - it's acting like a master node, it has been around a long time, blocking it might solve the problem. It might be suggestable that everyone remove it from the addnodes. Is there a config line to block it?

[allknowingeye]

I set up a client, the known broken 1.5.4.1a version on another machine and put your addnodes in excluding the 216.177.81.87. It started and found three new peers that the another one was not seeing, kinda does point to a code issue with peers. It's like it has decided 216.177.81.87 is the right chain (if it's allowed to see it) and is ignoring other peers. Perhaps it is right. Perhaps the chain that 216.177.81.87 and Crtypoia are on the winning chain. Kinda screwed up this situation is.

[CartmanSPC]

Globalcoin still uses IRC to communicate nodes. Make sure you don't have IRC being blocked for globalcoin-qt.exe on your personal computer...I did on my personal wallet computer

[almightyruler]

Globalcoin still uses IRC to communicate nodes. Make sure you don't have IRC being blocked for globalcoin-qt.exe on your personal computer...I did on my personal wallet computer

Good point, but really, that should only be necessary to help find initial peers. Normally, one brand new client connecting to a single peer (found via DNS seed, addnode, IRC etc) should result in all known peers being forwarded to that client. That assumes the code isn't buggy, of course...

I set up a client, the known broken 1.5.4.1a version on another machine and put your addnodes in excluding the 216.177.81.87. It started and found three new peers that the another one was not seeing, kinda does point to a code issue with peers. It's like it has decided 216.177.81.87 is the right chain (if it's allowed to see it) and is ignoring other peers. Perhaps it is right. Perhaps the chain that 216.177.81.87 and Crtypoia are on the winning chain. Kinda screwed up this situation is.

Yeah, at this point I'm not really sure how this can be fixed. I presume the fork differences are simply too great for the clients to figure it out themselves. This is not a minor squabble over who won the past couple of blocks; there's over 80,000 blocks discrepancy between the two chains. Even if new code is released with hardened checkpoints, there's going to be a lot of mining work lost, and potentially, double spends, which will affect the exchanges.

FWIW, I had previously blocked 216.177.81.87 and a couple of other nodes to stop my client getting stuck in the reorganise loop. Did it via firewall; I don't think there is any way to manually ban peers with the client config. Now that the work value has exceeded that of the "other" chain I've allowed them to connect again. There's still a lot of redundant, wasteful block fetching - most coin clients seem to do this when there's a fork - but no more endless reorganise loops.

Not really sure where we go from here.

[almightyruler]

How about we keep the two chains, and split the "globe" into hemispheres? Say hello to Globalcoin North, and Globalcoin South! 

[CartmanSPC]

One of the chains is not getting mined for long periods of time. Check https://chainz.cryptoid.info/glc/ which is on the shorter chain to see it.

If you click on "Overview" you will see that the shorter chain was not mined for very long periods of time. The longest being 10-13-2016 to 11-04-2016. Not one block during that time.

The longest chain has been mined consistently I believe. Is the client on the longest chain having any issues getting stuck? If it is not having any issues and it is the longest chain having been continuously mined then I think it is obvious that it is the winning chain?

[allknowingeye]

Is the client on the longest chain having any issues getting stuck? If it is not having any issues and it is the longest chain having been continuously mined then I think it is obvious that it is the winning chain?

I would agree. I can only get my two clients to see the longer chain, and I have put a miner on it to test and it works fine. I can send to Crytopia but not to Yobit (which I assume is then on the shorter chain). I agree the long one is the obvious winning chain but like it or not the client seems to have the last say.

[almightyruler]

I think first we need to define what 'longer' means.

The chain that is at a lower height, that Cryptopia was (possibly still is) and Megacrypton was/is on, is actually the longer chain by work.


11/14/16 05:37:46 SetBestChain: new best=00969007c862dcde3d04  height=2265261  work=6477767235355860  date=11/14/16 05:37:39

11/14/16 05:37:03 SetBestChain: new best=d0600e563e77b81813ad  height=2314415  work=6477410609666956  date=11/14/16 05:36:49


height 2314415 > height 2265261, but work 6477767235355860 > work 6477410609666956

[allknowingeye]

I am on the long chain with a present height of 2314617 at Mon Nov 14 01:07:55 2016. And we know that Cryptopia is as well because I have no issue sending test transactions that are from freshly minted blocks to them meaning they should be on the long chain (chain with the higher number of blocks). Yobit on the other hand seems to be on the shorter chain because I cannot send them test balances from freshly minted blocks. Work is not relevant. Blocks are the journal entries and determine the journal length in my opinion.

And somebody seems to be putting a fair bit of hash on it cause it has gone up 12 blocks in the minute it took me to type that.

[almightyruler]

Work is not relevant. Blocks are the journal entries and determine the journal length in my opinion.

Actually, work is entirely relevant. If the best chain was chosen based solely on block count, then someone could private mine at minimum difficulty, and periodically advertise their blocks to override miners who are working at a much higher difficulty. Using cumulative work (difficulty) rather than block count ensures that the chain which has used more mining power is considered the best, not just the one with more blocks.

Here's part of the code from AddToBlockIndex() which shows that if the chain on the block it has just processed has a greater work value (pindexNew->bnChainWork) than the current best chain's work value (bnBestChainWork), it switches chains.

Code:

    // New best
    if (pindexNew->bnChainWork > bnBestChainWork)
        if (!SetBestChain(txdb, pindexNew))
            return false;

I'm just making the point that according to the code, the chain with the smaller height is actually best... even though the client seems to be incapable of making the switch.

[allknowingeye]

Ok I get that, but the clients are not acting on that. And I know my client can see peers that are on both chains, and it just obviously goes on it's merry way. This does not bode well.

[allknowingeye]

Unfortunately when the client calls the reorganzie function it appears to only consider the Height to find a fork:

from Reorganize()

   // Find the fork
     CBlockIndex* pfork = pindexBest;
     CBlockIndex* plonger = pindexNew;
     while (pfork != plonger)
     {
         while (plonger->nHeight > pfork->nHeight)
             if (!(plonger = plonger->pprev))
                 return error("Reorganize() : plonger->pprev is null");
         if (pfork == plonger)
             break;
         if (!(pfork = pfork->pprev))
             return error("Reorganize() : pfork->pprev is null");
     }

The whole reorganize routine seems to ignore work and look only at block height.

[almightyruler]

Unfortunately when the client calls the reorganzie function it appears to only consider the Height to find a fork:

from Reorganize()

   // Find the fork
     CBlockIndex* pfork = pindexBest;
     CBlockIndex* plonger = pindexNew;
     while (pfork != plonger)
     {
         while (plonger->nHeight > pfork->nHeight)
             if (!(plonger = plonger->pprev))
                 return error("Reorganize() : plonger->pprev is null");
         if (pfork == plonger)
             break;
         if (!(pfork = pfork->pprev))
             return error("Reorganize() : pfork->pprev is null");
     }

The whole reorganize routine seems to ignore work and look only at block height.

Hmm, I'm not so sure. The while (plonger->nHeight > pfork->nHeight) | if (!(plonger = plonger->pprev)) subloop is only one part of the main loop. I think it may be to move the pointer on the longer chain backwards to the fork point - where the fork height is by definition going to be equal to or lower than the chain with the lowest height - but it's the if (!(pfork = pfork->pprev)) assign and if (pfork == plonger) test which actually finds the most recent common hash.

I checked a couple of other clients with more mature/maintained code and they contain the same sequence.

Disclaimer: I got up 20 minutes ago  

[almightyruler]

Anyway, this may all be moot - the 2.2M height chain, which overtook the 2.3M height chain by work value a few days ago, has now been eclipsed by the other chain. The 2.3M chain is now longer by work value, as well as greater in height. The db errors and massive reorg attempts (disconnect 33591, reconnect 83980) have started again...

A further thought, just to confuse things more: if transactions use funds from prior to the fork point, they should be considered valid by any client (regardless of its chosen chain) and so the one transaction may end up being incorporated into separate blocks, on two different chains. I sent a test transaction via a client on the 2.2M chain, but it's also confirmed on the 2.3M chain, which may explain why it suddenly appeared at Cryptopia after a couple of weeks (I'm guessing they saw the client having issues, resynced from scratch, and it chose the 2.3M chain). So much for test transactions to see which chain an exchange is on.

[almightyruler]

Here's a basic block explorer that's on the 2.3M chain

http://www.almightycoins.org/explorer/globalcoin

(half-assed hacky design and code, please don't hate)

Note that the block reward on this chain halved a few days ago.

[allknowingeye]

It's funny neither of the explorers ever show my ip and I have been mining it since day one. Now that reward has dropped by half again to 0.390625 it is going to be harder again to get any sane person to mine it. I have split off one fury to dedicate it to Globalcoin so it should keep moving, impossible to even break anywhere near even on electricity for this one anymore.

[almightyruler]

It's funny neither of the explorers ever show my ip and I have been mining it since day one.

I accidentally deleted globalcoin.conf earlier, which had a bunch of manual addnodes, so it's possible that the client would have tried your IP again at some point. Then again, I just manually logged into IRC, and I can see peer IPs in the channel that the client is not connected to. The peer discovery system really does seem to be quite flaky.

Now that reward has dropped by half again to 0.390625 it is going to be harder again to get any sane person to mine it. I have split off one fury to dedicate it to Globalcoin so it should keep moving, impossible to even break anywhere near even on electricity for this one anymore.

I think there was some discussion in this thread a few months ago about an algo change and other ways (such as PoS) to keep the chain moving and secure when PoW was no longer profitable or technically viable. If nothing changes, the reward will eventually drop so low that it will be considered dust: either minted blocks containing dust will be ignored when trying to send funds, which removes all incentive to mine, or even worse, the coinbase transaction will be rejected outright by both the client and network when trying to form the block, so no new blocks can be added to the chain.

   "mininput" : 0.00010000,

Hmm, I guess there's a fair way for it to go to drop that low, and if it did then most miners probably would have abandoned the coin long before then...

[allknowingeye]

I contacted Yobit, and then are going to update their wallet (will take them some time they said). That should put both exchanges on the same chain, which should put this to bed. Eventually anyone on the short chain that will want to send to an exchange are going to need to update to do it. I also notified Megacrypto, there is very little activity but it's better if they are all on the right chain.

[ave_chaincoin]

Hi guys,

So what nodes should I add to connect my client to the "proper" chain? 

[allknowingeye]

Try these two:

203.20.114.252
216.177.81.87

These two are actually alive, most of the rest are non-responsive.