Bitcoin Forum
December 13, 2024, 08:28:47 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: No Active Poll
  n/a - 0 (0%)
N/A - 0 (0%)
Total Voters: 0

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 »  All
  Print  
Author Topic: CryptoCoin Explorer - Coin Block Explorers.  (Read 30831 times)
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 18, 2013, 09:27:05 PM
 #321

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 (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 19, 2013, 12:47:18 AM
 #322

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   Shocked
Petr1fied
Hero Member
*****
Offline Offline

Activity: 630
Merit: 502


View Profile
June 19, 2013, 10:53:53 AM
 #323

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 (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 19, 2013, 06:50:08 PM
 #324

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
Legendary
*
Offline Offline

Activity: 2198
Merit: 1014


Franko is Freedom


View Profile WWW
June 20, 2013, 12:31:13 PM
 #325

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. Smiley i'll be making the commit today. Thanks again man! What is your FRK address? I'll send you a couple for the find.

Fortune Favors the Brave
Borderless CharityEXPANSEEXRAllergy FinderFranko Is Freedom
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 20, 2013, 09:04:43 PM
 #326

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
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


Bytecoin: 8VofSsbQvTd8YwAcxiCcxrqZ9MnGPjaAQm


View Profile WWW
June 21, 2013, 02:51:07 PM
 #327

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 (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 21, 2013, 04:45:32 PM
 #328

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
Full Member
***
Offline Offline

Activity: 132
Merit: 100



View Profile WWW
June 22, 2013, 07:34:35 AM
 #329

DGC explorer is down

Secure Online Wallet - https://mywl.lt - Vote for your favorite coin
IRC Wallets #digitalcoin on irc.freenode.net
DGC Faucet Free digitalcoin Open source faucet written in NodeJS
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 22, 2013, 08:03:37 AM
 #330

DGC explorer is down

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

Everything is back up now.



everybodyclapyohands
Full Member
***
Offline Offline

Activity: 132
Merit: 100



View Profile WWW
June 22, 2013, 08:43:03 AM
 #331

DGC explorer is down

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

Everything is back up now.






Thanks!

Secure Online Wallet - https://mywl.lt - Vote for your favorite coin
IRC Wallets #digitalcoin on irc.freenode.net
DGC Faucet Free digitalcoin Open source faucet written in NodeJS
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 23, 2013, 09:22:03 AM
Last edit: June 23, 2013, 07:25:39 PM by dreamwatcher
 #332

Double Post...Please see below.  Grin


dolfcao
Member
**
Offline Offline

Activity: 98
Merit: 10



View Profile WWW
June 23, 2013, 09:36:48 AM
 #333

I hope rec can be added on cryptocoin explorer

RealCoin: RRUfzu9qeUU9qAeHJARpGVqDQsXEU7u4d9
RealCoin Mining Pool: www.realcoin.org:18888
My personal website: www.needdo.com
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 23, 2013, 05:33:21 PM
 #334

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 (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 23, 2013, 06:41:37 PM
Last edit: June 23, 2013, 06:56:34 PM by dreamwatcher
 #335

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

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  Grin  ). 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 (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 23, 2013, 07:35:28 PM
 #336

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.  Wink


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
Legendary
*
Offline Offline

Activity: 3108
Merit: 1359



View Profile
June 23, 2013, 09:24:06 PM
 #337

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

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.  Smiley
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 24, 2013, 04:33:05 PM
 #338

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   Cheesy

Anyway, all the explorers are back up.

bigdaub
Full Member
***
Offline Offline

Activity: 179
Merit: 100



View Profile
June 24, 2013, 05:33:28 PM
 #339

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   Cheesy

Anyway, all the explorers are back up.



Thanks, I couldn't find BBQ on CoinChoose this morning Sad Keep up the great work!
dreamwatcher (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile WWW
June 24, 2013, 09:46:45 PM
 #340

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

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.  Smiley

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!