As has been announced, I will be shutting down CCE for now. I will not be renewing any sponsorship's and explorers are being shut down as they expire. There are a few reasons for the decision to shutdown related to the changing market of cryptocurrencies. I am also attending college again and working on a electronics specialization. I will be attending full time the next couple of semesters which will severely limit my time for other projects. CCE might come back at a later date and I continue to hold the domains, rights etc to the CCE brand. Because BTB has been on CCE for so long, I have been reluctant to shutdown the BTB explorer due to a lack of full fledged replacement explorer for BTB. Searching around a bit I found: https://prohashing.com/explorer/Bitbar/The CCE Bitbar explorer will be shutdown by the weekend and I wish all of you the best of luck in the coming years. |
|
|
|
Good and bad news  Good news - I finished coding the markets module of CCE for the Cryptopia API. The BTB explorer on CCE now has Cryptopia in the market header. Bad news: I believe we are looking at a hard fork due to a client update. After a complete fresh chain download with addnodes that were given to me on the longer chain, the daemon on CCE ended up on the same block (150545). CCE peer list: {
"addr" : "172.127.121.113:59629",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573183,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "173.65.129.85:8777",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573189,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "109.228.4.100:8777",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573191,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "108.61.10.90:8777",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576813,
"conntime" : 1453573191,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "89.27.70.48:8777",
"services" : "00000001",
"lastsend" : 1453577099,
"lastrecv" : 1453576812,
"conntime" : 1453573192,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "94.23.54.195:49148",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573226,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "144.76.91.109:8777",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573243,
"version" : 60005,
"subver" : "/Satoshi:0.7.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 150545,
"banscore" : 0
},
{
"addr" : "198.0.43.101:58716",
"services" : "00000001",
"lastsend" : 1453577101,
"lastrecv" : 1453576812,
"conntime" : 1453573245,
"version" : 60006,
"subver" : "/Satoshi:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150545,
"banscore" : 0
},
{
"addr" : "148.251.19.213:62161",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573272,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "81.230.143.200:46978",
"services" : "00000001",
"lastsend" : 1453576813,
"lastrecv" : 1453576812,
"conntime" : 1453573291,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "91.121.120.218:54756",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453573291,
"version" : 60006,
"subver" : "/Bitbar:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150882,
"banscore" : 0
},
{
"addr" : "159.205.246.59:58248",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453577091,
"conntime" : 1453573692,
"version" : 60005,
"subver" : "/Satoshi:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150545,
"banscore" : 0
},
{
"addr" : "87.182.80.119:43986",
"services" : "00000001",
"lastsend" : 1453576783,
"lastrecv" : 1453577099,
"conntime" : 1453573970,
"version" : 60006,
"subver" : "/Satoshi:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150239,
"banscore" : 0
},
{
"addr" : "68.191.93.33:49519",
"services" : "00000001",
"lastsend" : 1453576812,
"lastrecv" : 1453576812,
"conntime" : 1453575612,
"version" : 60005,
"subver" : "/Satoshi:0.7.4/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 150545,
"banscore" : 0
}
]
It appears the clients responding with the subversion "/Bitbar:0.7.4/" are on the chain that is about block 150882. The clients (including CCE) that are on subversion "/Satoshi:0.7.4/" are on the chain that is on block 150545. So now the question is, which client version is going to become the official client? |
|
|
|
So my wallets are in sync with ispace and cryptopia, but not cce.
Anybody else ??
note: cce is almost 190 minutes from last block.
It appears there may be another fork that a majority amount of miners have switched to. The coin daemon and explorer at CCE are in sync with each other but there are only a half dozen or so peers connected to the daemon. So again, the community needs to decide which fork to use. The issue I have is which chain should I try to resync the coin daemon on CCE, if I should resync at all. |
|
|
|
|
I want to reassure people about their wallets during this chain fork.
The wallet.dat files' primary purpose is to store the private keys to the addresses you own.
It does contain a mini ledger of sorts so that the client/daemon does not have to re-scan the entire blockchain every time you start it.
The transaction/balance information in the wallet.dat file is not "canon" so to speak. It is really just there for display purposes.
The true balance/transaction information is in the block chain itself. When the Client/daemon detects that the blockchain might not match the ledger in the wallet file, it will re-scan the blockchain and correct the balance/transaction information in the wallet.dat. This normally happens when a chain reorganization takes place, or a new/different wallet.dat file is presented.
When the resolution of a fork occurs, all transactions on the rejected fork no longer exist. If person A sent 10 coins to person B and they were on the rejected fork, person A would have the 10 coins back in his wallet and person B would have never received those coins because the transaction no longer exists.
The people that have the potential to lose coins are those who mined POW blocks on the rejected chain. Those will be lost.
Although the coins gained on the rejected chain through POS would disappear, the coins that were used to stake a block would still have the same maturity as if the fork did not happen and will stake new blocks on the correct chain.
Take all the precautions you wish, whatever makes you comfortable. When the correct chain is decided, your client/daemon will automatically adjust your wallets ledger.
ETA: This only applies to transactions after the fork. Any transactions before the fork are unaffected.
|
|
|
|
|
I also wanted to add that CherryPy is configured to be run through a proxy. If you want to directly access it , most likely you will need to change the server.conf file.
tools.encode.on: True
tools.gzip.on: True
tools.gzip.mime_types: ['text/html', 'text/plain', 'application/json', 'text/javascript', 'application/javascript']
tools.proxy.on: True
|
|
|
|
The stats module runs quickly as it is using MySql itself to sort most of the results. Hash rate, difficulty and peer info are directly queried from the coin daemon. Except for the sever log, it is normal for there not to be logs as they are only written to when warnings/errors occur. The SQL error, I have not seen. However it appears you are using MariaDB, CCE and the SQL file I have included are written with InnoDB. ERROR:root:06-29 16:25:05 'networkhashps' : General stat module error Hash rate can only be obtained if the coin daemon provides it. As outlined in the instructions: hashrate:
Boolean indicating if the network hash is available by the daemon.
Network hash rate can only be obtained from the coin daemon.
hashfield: (Suggested: networkhashps)
Label of the field network hash rate is returned by the coin daemon.
ratelabel: (Suggested: MH or GH)
Label to use for the hash rate on the index web page.
hashmult:
Hash rate multiplier to use for storing hash rate at desired level.
Example: Daemon output is 5678 H/s. Use the multipler 0.001 to store as 5.678.
The CCE web server uses Apache for http proxy and to serve static files. It also requires bootstrap 3 be served statically or hosted (In which case change the header in base.html) Install Bootstrap3 css and js files to their appropriate css and js directory in document root.
Alternately, find a host for bootstrap3 and change the base.html header to reflect.
As outlined in the instructions, you can change the port the CherryPy server runs on in the server.conf file [global]
server.socket_port:8222 If one wishes to use another web server then Apache, one will need to configure according to the server. It needs to proxy/reverse proxy and serve static files.( Bootstrap 3 and any images) I believe the issues with the text based browser may be related to not having or using bootstrap 3. |
|
|
|
New commit pushed.  Added: - Configuration options to set MySQL server IP address and port
- Configuration option to set RPC timeout
- Instructions on how to set up an empty database from the command line
Fixed: - Type errors when logging or sending messages to stderr. Exception descriptors are now always cast to string
- The database loader will now throw an exception when a block height of "-1" is sent to the block parser instead of attempting to process it.
|
|
|
|
How much space does the DB require? Guess I'll just have to test in on the VPS this weekend. My test VM with 16GB storage ran out of diskspace after ~800k blocks. Also, I can't find a way to specity the mysql host in the configuration file. Does it absolutely need a local mysql server to function? I'd prefer using a remote mysqldb that could handle all the queries more easily. Can I change the host address in comm.py without breaking it?conn = pymysql.connect(db=CONFIG["database"]["dbname"], host='127.0.0.1', port=3306, user=CONFIG["database"]["dbuser"],passwd=CONFIG["database"]["dbpassword"]) Changed the host and it works with a remote server Lol... with abe it was a little harder to get this working... Lookin' forward to a completely loaded DB \(^_ ^)/ The size of the database depends greatly on the number of transactions in the block chain. Using HoboNickels as an example: ~2.3 Million blocks - ~6.5 million TX_IN and ~6.5 million TX_OUT Size of the active database: 6.7 GB I will add an option to set the host address for the database in the next commit. Personally, I have never had need for it so I never thought to put it in. This is happening on my server after every few weeks . We have a getblock call to altcoin daemon for each blocks. After few block numbers bitcoind RPC hangs (I have tried waiting for 30 min, but doesn't help, have to kill daemon and restart). I'm also using a node to make rpc calls.
This is why there are two timers in the database loader. The main loop timer is set at 5 minutes while individual RPC calls are set at 10 seconds. Since adding the timers I have not had to reset the loader or the daemons. If the loader gets interpreted/timeout, the next time it is called it re-parses the last 5 blocks including transactions, this helps guarantee information integrity if the loader is interrupted in the middle of parsing blocks/transactions. I have not noticed the coin daemons RPC completely locking up where it will not answer subsequent calls, they appear only to ignore/hang on one call. The things like the rich list and largest tx... is that processed after all the blocks are loaded or when invoking stats.py? I imagine it will take some time to process it on 1.7M blocks.
The stats module is called when the database loader has completed its cycle. However, the stats module can be run independently, but the information will only be accurate to the point the database is loaded. Largest TX is populated on the fly as the loader is parsing transactions, again only will be acurate to the point where the database is loaded. Added - Running the stats.py module while the loader is running might interrupt the loader due to the way Python handles module imports. If one really wants to run the stats module while the loader is running I would suggest making a copy of comm.py named something like comm2.py and change the import in stats.py to import the copied file instead of comm.py. |
|
|
|
I will address some of these annoyances mentioned in the above posts on the next commit |
|
|
|
akira@positron:~/CCE$ ./dbload.py -n -v
Processing Block: 6368 of 1637812
Main Loop cannot concatenate 'str' and 'int' objects
akira@positron:~/CCE$ ./dbload.py -v
Recheck Called
Processing Block: 7188 of 1637812
This is due to the time-out in normal mode , you later discovered to correct with the -l option to extend the time-out to 24 hours. "Main Loop cannot concatenate 'str' and 'int' objects" is a bug corrected in the latest commit. It was purely a cosmetic bug with sending the error string to stderr, no function involved. Edit - After second look, the error occurred during a proper build (-n). My guess is your coin daemon is running slow or is sluggish to respond. The RPC interface in comm.py will timeout the connection after 10 seconds. If the daemon is responding slow, it would also account for the slow build time. Processing Block: 10192 of 1637812
Main Loop (1062, u"Duplicate entry '-1' for key 'PRIMARY'") Odd error that pops up once in a great while when restarting during the initial load. Just remove the row in the block table with the height "-1" and continue. Or Processing Block: 13430 of 1637812
Main Loop sequence index must be integer, not 'str' Related to the first to question. Make sure you are using the latest version. I'm confused now  Edit: Looks like it's solved by adding the -l argument. - This is correct The 250 block check takes only a second or two. It is asking for the block hash from the coin daemon and checking it against the database. If you feel that is too long it can be adjusted in the configuration file. There is also a 15 second delay when starting the loader without the new database option. This is to allow the coin daemon time to catch orphans it discovers shortly after calling the loader through block notify. Both of these functions run once when the loader is started, when you see the count-up they are no longer being called. As to questions about speed of the initial load, it is hard to answer without actually running it on whatever system you are using. The CCE servers have about a half dozen explorers each running and generally have a CPU usage around 0.8 - 1.5 on a six CPU system. This is running the coin daemons, loaders and web servers. I recently built a database on a 600K + block chain and the initial load took about 10 hours. The initial load can take some time, but after the initial load is finished it runs smooth and quick. |
|
|
|
taking a tumble at it tonight , looks tight , still don't have it woking yet though !! lol
How is it going along? Any questions? |
|
|
|
New commit pushed: - Fixed timeout error bug (issue #1)
- Documentation corrections
|
|
|
|
There are couple of fixes in the documentation that will show up in the next commit. The coin daemon needs to run with the daemon option. Either add the option "daemon=1" in the daemon configuration file or run the daemon with the --daemon switch. It has become habit for me to always run the coin daemons with the switch which is why I overlooked it in the documentation. The apache2 http proxy module is actually called proxy_http. The command to activate it should read: a2enmod proxy_http. In the instructions I refer to it incorrectly as http_proxy. |
|
|
|
This is great news. I have followed your work on them for some time. Im a bit surprised it went open source but am happy you did.
Well I guess my weekend is booked now lol
There are a few reasons I released an open source version of CCE. - To contribute to the open source community. My knowledge of development has been expanded by the open source community. I felt it was appropriate to give something back.
- I wanted to show the cryptocoin community how much the coin daemon RPC has improved over the years and what can be done with it.
- Of course on the business side, it is great PR. It can help draw attention to CCE and the upcoming 4.0 update.
In my view, the open source version is not particularly special in terms of coding and I think any moderately skilled programmer could have wrote it. The open source version is very basic and truly meant as a foundation to build on. The full closed source version is more robust and much more feature rich. CCE 3.99 already has many more features and a full API vs the open source version, including some of the commands needed for "lite" clients, the API will be further expanded in full version 4.0. The open source version fits into CCE as I am planning on offering 4 tiers of explorers on CCE once the full version 4.0 is finished. The free tier will basically be the open source version minus the two API commands and supported by ad revenue. The removal of the API is mostly due to the fact the API calls do not generate ad revenue. I may start setting up explorers on the free tier before the full version 4.0 is released on CCE. More information on the full version 4.0 and cryptocoinexplorer.com will be in the official thread at: https://bitcointalk.org/index.php?topic=922515.0. |
|
|
|
New commit pushed to the repository. - Bug Fix: Replaced a line of code that was unintentionally removed. This line checked the stats Boolean in the configuration file.
- Documentation: Various corrections. Moved the database loader and web server documentation to separate folder "docs".
|
|
|
|
|
Show Posts
