CryptoCoin Explorer - Coin Block Explorers.

[dreamwatcher]

THE JKC PPS POOL IS OPEN FOR LIVE TESTING.
The live testing phase has started. First stage will be stratum only.
The pool is running as it would normally run and payouts are in effect.
jkc.cryptocoinmine.com
Port: 8080  stratum

[dreamwatcher]

UPDATE:

The last couple of days I have learned more about hash rates, difficulty, POW/POS and even more about how ABE works.

In the latest commit of PPC, Sunny has put a getnetworkghps RPC call into the PPC daemon. This call has no parameters and uses a 72 block exponential moving average to estimate current PoW block spacing.
In light of how far off my API implementation is compared to the numbers this new RPC call returns, I am scraping the current POS/POW CCE network hash rate API and will instead pull the hash rate from the daemon.
NVC and BTB will get a network hash API just as soon as their developers adopt the getnetworkghps RPC call or I patch the daemons myself.

To all other alt-coin developers:

I have noticed that many of the coins have not changed the getnetworkhashps RPC call to fit their coin and are still using the LTC parameters.

In bitcoinrpc.cpp:

Code:

Value GetNetworkHashPS(int lookup) {
    if (pindexBest == NULL)
        return 0;

    // If lookup is -1, then use blocks since last difficulty change.
    if (lookup <= 0)
        lookup = pindexBest->nHeight % 2016 + 1;

    // If lookup is larger than chain, then set it to chain length.
    if (lookup > pindexBest->nHeight)
        lookup = pindexBest->nHeight;

    CBlockIndex* pindexPrev = pindexBest;
    for (int i = 0; i < lookup; i++)
        pindexPrev = pindexPrev->pprev;

    double timeDiff = pindexBest->GetBlockTime() - pindexPrev->GetBlockTime();
    double timePerBlock = timeDiff / lookup;

    return (boost::int64_t)(((double)GetDifficulty() * pow(2.0, 32)) / timePerBlock);
}

Value getnetworkhashps(const Array& params, bool fHelp)
{
    if (fHelp || params.size() > 1)
        throw runtime_error(
            "getnetworkhashps [blocks]\n"
            "Returns the estimated network hashes per second based on the last 120 blocks.\n"
            "Pass in [blocks] to override # of blocks, -1 specifies since last difficulty change.");

    return GetNetworkHashPS(params.size() > 0 ? params[0].get_int() : 120);
}

In the lines:

Code:

 lookup = pindexBest->nHeight % 2016 + 1;

"2016" needs to be changed to the number of blocks between difficulty changes.

Code:

return GetNetworkHashPS(params.size() > 0 ? params[0].get_int() : 120);

"120" needs to be changed to the target number of blocks per day for the coin.


It would help your users and myself if each developer would change these parameters instead of patching all the coins on CCE myself   

[Petr1fied]

Thanks for the useful info but patching this code would create a hard fork wouldn't it?

Also I'm not so sure basing the network speed on the last 24 hours is necessarily a good idea. To make a good calculation of what the difficulty needs to move to, using a block value that equates to maybe the last 1-2 hours is probably a better indication of the real network rate at any one time.

[dreamwatcher]

Thanks for the useful info but patching this code would create a hard fork wouldn't it?

Also I'm not so sure basing the network speed on the last 24 hours is necessarily a good idea. To make a good calculation of what the difficulty needs to move to, using a block value that equates to maybe the last 1-2 hours is probably a better indication of the real network rate at any one time.

No, this would not be a hard fork. The function is completely optional and does not run unless called through the RPC, and has nothing to do with the creation of the block chain. One could remove it or make it return a rude gesture , it would not change the coin/chain itself in any way.

Yes 24 hours is the best indicator. It was the way the code was originally set up in the LTC daemon that all the new coins have forked from.

If one uses a couple of hours, plenty of anomalies can pop up due to normal variance. Nothing made that more clear to myself, then when I applied the precise difficulty accounting and averaging system I created to a couple of the explorers.

I am not going to argue with anybody about this, they are your daemons. Change them, don't change them. If a developer does not fix it, I will do it myself and your publicly available daemons can continue to be inaccurate.

[defaced]

Thanks for the useful info but patching this code would create a hard fork wouldn't it?

Also I'm not so sure basing the network speed on the last 24 hours is necessarily a good idea. To make a good calculation of what the difficulty needs to move to, using a block value that equates to maybe the last 1-2 hours is probably a better indication of the real network rate at any one time.

No, this would not be a hard fork. The function is completely optional and does not run unless called through the RPC, and has nothing to do with the creation of the block chain. One could remove it or make it return a rude gesture , it would not change the coin/chain itself in any way.

Yes 24 hours is the best indicator. It was the way the code was originally set up in the LTC daemon that all the new coins have forked from.

If one uses a couple of hours, plenty of anomalies can pop up due to normal variance. Nothing made that more clear to myself, then when I applied the precise difficulty accounting and averaging system I created to a couple of the explorers.

I am not going to argue with anybody about this, they are your daemons. Change them, don't change them. If a developer does not fix it, I will do it myself and your publicly available daemons can continue to be inaccurate.

Yea man, good find i dont know how i over looked this. i'll be making the commit today. Thanks again man! What is your FRK address? I'll send you a couple for the find.

[dreamwatcher]

PPC and NVC now have hash rates displayed on the chains page.

The hash rates are taken directly from the daemon. The explorers are also building a database of hash rates for users that want to calculate historical data.

The hash rates are refreshed and stored every block.

Once 24 hours of data is collected I will open up the getnetworkhash API to reporting past data.

For now the API only reports the current hash rate.

Code:

Shows network hash rate reported by the daemon.
/chain/CHAIN/q/getnetworkhash?format=[list,json,web]
All format parameters are optional.
Invalid entries default to web style output. 

All the explorers are going to be moved to this system as the daemons networkhashps are patched or I patch them myself.

This system will also eliminate the question of accuracy and parameter settings using the getnetworkhash API. All data will be derived from the daemon, so perceived inaccuracies can be directed at the coin developers. In the cases where I patch the daemons myself, I am only changing the parameters to match what the coin developers have stated are the blocks between difficulty and the target number of blocks per 24 hrs.
Some coins will require a slightly different approach, mostly those with very short difficulty re target times. If the coin developer does not patch a proper solution, I will simply take an average difficulty over the number of blocks targeted per day and use it for a calculation.

[Walter Rothbard]

dw, this is probably answered elsewhere, but is there an IP address the public can use if we want to add cryptocoin explorer as a peer to our own wallets, i.e., in an addnode= line in the .conf file?

[dreamwatcher]

dw, this is probably answered elsewhere, but is there an IP address the public can use if we want to add cryptocoin explorer as a peer to our own wallets, i.e., in an addnode= line in the .conf file?

Yes, but the IP address depends on the coin.

PPC,TRC,FRC,NVC,FTC,BBQ,BTE,CNC and BTB

addnode=69.164.204.19


DGC,WDC,FRK,JKC and GLD

addnode=50.116.22.43

If one is using Flagfox or similar tool, one can go to the coins explorer and get these and future IP addresses.

[everybodyclapyohands]

DGC explorer is down

[dreamwatcher]

DGC explorer is down

DGC,WDC,FRK,JKC and GLD were down while I was performing some important maintenance on the server. 

Everything is back up now.

[everybodyclapyohands]

DGC explorer is down

DGC,WDC,FRK,JKC and GLD were down while I was performing some important maintenance on the server. 

Everything is back up now.

Thanks!

[dreamwatcher]

Double Post...Please see below. 

[dolfcao]

I hope rec can be added on cryptocoin explorer

[dreamwatcher]

Just wanted to give the community a little preview of some of the changes planned for CCE.

It is looking more and more like a complete rewrite of ABE, probably so much so it will not be ABE anymore.

For coin developers, you will have API access to a large information box on your coins homepage on CCE.

One corner of the box would display the current client/daemon version number. Across the top line, you could activate a red headline for news needed immediate attention.

As it stands now the Home Page starts with the coin symbol and name as the headline. The network hash rate goes below it. The basic information on the last five blocks is next. Then two boxes of information about the coin. The basic side would have web links and the Tech. side would have  ports,trusted nodes, address version etc.

The developers box comes under that and at the bottom the donation information. Mind that is a  quick mock up, done in the forum window. There are going to be some major changes under the hood as well.

This is the home/default/search page every coin explorer is going to have separately. This is where the users will land whenever using CCE.Let me know what you think.

($$$) CoinExplorer
Network Hash estimate: 321 M/H

Chain start date / age     Number of coins mined


Height     AGE      TRANSACTIONS      Total Sent     Total Size
1
2
3
4
5

SEARCHBOX
20,40,80,500,2016

Basic Information Box                         Techinical Information
                                                                                                                     
Official Website                                           RPC Port
Offical Forum                                               P2P Port
    Source                                                     address version
other download                                          trusted nodes




Large news box that developers can access through an API key.

Donation Information

[dreamwatcher]

Some of the internal changes, or should I say a new block explorer  

Dumping Fastcgi and using Cherry.py. One of the large advantages Cherry.py has over Fastcgi is the elimination of opening a new Python thread with every operation/request. This will make the explorer faster and lighter on resources. I also want to look into using Fastcgi/flup with Cherry.py. There are multiple ways to configure this and Cherry.py appears to be very flexible about it.

I am also looking at Mako templating.

At least at first, using PyMySql database API. I have found it to be very fast compared to the database API ABE uses. I also need to look at python Postgresql APIs and find the best one for this application.

With the current explorers there is too much interpretation of data with requests. I am sure Abe's developer had his reasons for storing data in machine friendly, close to the original data read from the block files. I, however, believe in the opposite approach. Why keep reinterpreting the same data over and over.
The new database structure will store everything in a human readable format. This will greatly reduce the number of tables and shrink the database.

The new explorers will no longer read and try to interpret the BLK files. I can get all the information needed from the daemons with a couple of small patches to the daemons. The main one being the commit/patch Balthazar uses on Novacoin to allow the daemon to look up and display any transaction, not just the ones in the wallet. The PPC and NVC commits (Thanks again Sunny and Balthazar) that allow the daemon to calculate network hash rates has been invaluable when calculating the split difficulty and targeting times of POS/POW.
The daemons in general give out much more information then in the past and I think the days of scanning BLK files are dying out.

I realize when first building a database, it will put a large amount of stress on the daemon. This is perfectly fine as I shut down web access when rebuilding databases anyway, and it is a rare occurrence  (For the most part    ). After the initial database build, the explorer will make a few requests, more depending on the number of transactions, every block as blocknotify is tripped.

The  purpose of the redesign is to make a lighter and faster explorer that only deals with information people need and stop calculating information people rarely use or understand. This will allow CCE to carry more coins using the current server(s) setup.
Secondary to my purpose, when the new explorers go open source, it will be very easy to adopt them to any coin. Because they get the data directly from the daemon there is no longer the need to try and tailor actual code to the block structure itself. Everything needed to make it work will be able to be done in the configure file.

Cosmetically, the sites will be separating the coins into the Home pages I mentioned above, completely solving the cluttering problem the home page suffers now. It also gives the appearance of a site tailored for the coin, as it will serve as an information center and another way for developers to communicate with the coin community's. The quick reference links and technical specs will help people out without having to hunt and search for these items.

Well, I have rambled on long enough, I will post as more information becomes available.




TLDR: A bunch of technical stuff and reasons for a ground up redesign of the explorers.

[dreamwatcher]

I just wanted to add, that I am not criticizing John Toby or the ABE project in the least.

John has been slowly moving in this direction himself with the reading of the memory pool to preload transactions.

What I am proposing was not possible until recently, and ABE has proven itself a cornerstone in the alt-coin community. 


I am sure the John will improve/make a better version ABE that will give the new CCE explorers a run for the money, his programming skills are far more advanced then mine.

[Balthazar]

Some of the internal changes, or should I say a new block explorer  

Dumping Fastcgi and using Cherry.py. One of the large advantages Cherry.py has over Fastcgi is the elimination of opening a new Python thread with every operation/request. This will make the explorer faster and lighter on resources.

It's a problem of apache-mod-fcgid, but not fastcgi. Normal fastcgi implementation should reuse threads instead of restarting them.

Try nginx & spawn-fcgi, this should be much faster. Also, it has smaller memory footprint.  

[dreamwatcher]

I apologize for the downtime this morning.



I guess this is what I get when I decide to sleep in one morning.

The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.

Add to the list of things to add during the explorer rewrite  

Anyway, all the explorers are back up.

[bigdaub]

I apologize for the downtime this morning.



I guess this is what I get when I decide to sleep in one morning.

The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.

Add to the list of things to add during the explorer rewrite  

Anyway, all the explorers are back up.

Thanks, I couldn't find BBQ on CoinChoose this morning Keep up the great work!

[dreamwatcher]

Some of the internal changes, or should I say a new block explorer  

Dumping Fastcgi and using Cherry.py. One of the large advantages Cherry.py has over Fastcgi is the elimination of opening a new Python thread with every operation/request. This will make the explorer faster and lighter on resources.

It's a problem of apache-mod-fcgid, but not fastcgi. Normal fastcgi implementation should reuse threads instead of restarting them.

Try nginx & spawn-fcgi, this should be much faster. Also, it has smaller memory footprint.  

I most definitely will.

My thoughts behind Cherry.py were along the lines of using a web framework/server written in the same language as the main application, might give an advantage.

The learning curve would be shorter also.

After some thought, it seems less likely the case and perhaps going with a more established framework/web server would be a better idea.