Pages:
Author

Topic: [GLC] Globalcoin | 4 Year Anniversary 1.5.4! | NO IPO, NO PREMINE | [SCRYPT] - page 14. (Read 225833 times)

legendary
Activity: 1270
Merit: 1000
- Consumer client IPs which do not accept inbound connects, perhaps due to the router being misconfigured

My desktop wallet (1.5.3 I think) does not have uPNP option compiled into it. Perhaps we would see more clients if a version was released with uPNP enabled and selected by default. Have not checked if 1.5.4 has this feature compiled in as I stopped using it for some reason I don't remember...think it was buggy with the built in block explorer or something.
legendary
Activity: 2268
Merit: 1092
Try these two:

203.20.114.252
216.177.81.87

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

Combine the following:

- Only a couple of hands worth of peers
- Consumer client IPs which do not accept inbound connects, perhaps due to the router being misconfigured
- Exchange client IPs which do not accept inbound connects, for security purposes
- A peer discovery system that doesn't seem to properly propagate all peer IPs (or perhaps the client isn't trying them all)

...and you get Globalcoin! Wink

Speaking of peer discovery, on one of my full time nodes it's interesting to see that out of the 6174 unique IPs tried within the past couple of days, 5719 have a "last seen" value of at least 12 months, with some being last seen over 3 years ago (probably when GLC first started). Not sure if there's much value in trying to repeatedly connect to an IP that hasn't had a client running on it for 3 years.
sr. member
Activity: 361
Merit: 250
Try these two:

203.20.114.252
216.177.81.87

These two are actually alive, most of the rest are non-responsive.
newbie
Activity: 50
Merit: 0
Hi guys,

So what nodes should I add to connect my client to the "proper" chain?  Huh
sr. member
Activity: 361
Merit: 250
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.
legendary
Activity: 2268
Merit: 1092
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...
sr. member
Activity: 361
Merit: 250
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.
legendary
Activity: 2268
Merit: 1092
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.
legendary
Activity: 2268
Merit: 1092
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... Sad

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. Smiley
legendary
Activity: 2268
Merit: 1092
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  Wink
sr. member
Activity: 361
Merit: 250
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.
sr. member
Activity: 361
Merit: 250
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.
legendary
Activity: 2268
Merit: 1092
Work is not relevant. Blocks are the journal entries and determine the journal length in my opinion.

Actually, work is entirely relevant. Smiley 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.
sr. member
Activity: 361
Merit: 250
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.
legendary
Activity: 2268
Merit: 1092
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
sr. member
Activity: 361
Merit: 250
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.
legendary
Activity: 1270
Merit: 1000
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?
legendary
Activity: 2268
Merit: 1092
How about we keep the two chains, and split the "globe" into hemispheres? Say hello to Globalcoin North, and Globalcoin South!  Cheesy
legendary
Activity: 2268
Merit: 1092
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 Smiley

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.
legendary
Activity: 1270
Merit: 1000
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 Smiley
Pages:
Jump to: