Dear Dreamwatcher,
Due to an attacker running up the mining difficulty, we've had to adjust the block height of the upcoming fork. Please update your wallets with the update just released today (version 0.7.2.0). You must update your client before block 251230 to remain compatible with the network.
Please update now! >>> http://www.gldcoin.com/get-started/
You should close your Goldcoin client, if it's running, before attempting to install this patch. The development team is currently on standby in the forum in the event you require technical assistance during this time.
Thank you!
Topic: CryptoCoin Explorer General Thread (Read 1886 times)
The open source 4.0 thread is located at:
https://bitcointalksearch.org/topic/open-source-cce-40-block-explorer-1088291
https://bitcointalksearch.org/topic/open-source-cce-40-block-explorer-1088291
The first example explorer for Open Source CCE 4.0 is up!
As mentioned before it is a Blakecoin explorer.
http://openblc.cryptocoinexplorer.com/
As mentioned before it is a Blakecoin explorer.
http://openblc.cryptocoinexplorer.com/
I was able to finish the documentation sooner then I thought 
The open source CCE 4.0 repository is now up:
https://github.com/cryptocoinexplorer/Open-Source-CCE-4.0
The example server will be up this weekend.
The open source CCE 4.0 repository is now up:
https://github.com/cryptocoinexplorer/Open-Source-CCE-4.0
The example server will be up this weekend.
The open source code is ready to be published!!!!
I am in the process of setting up an example explorer on CCE.
The example explorer will be using Blakecoin. At a later date I will set up an example explorer using a POS chain, most likely HyperStake.
I just need to finish the documentation. The full repository should be up this weekend.
I am in the process of setting up an example explorer on CCE.
The example explorer will be using Blakecoin. At a later date I will set up an example explorer using a POS chain, most likely HyperStake.
I just need to finish the documentation. The full repository should be up this weekend.
Description of the float rounding issue:
Float types are designed for precision over accuracy.
A number like this: 8813.021351 , can turn out like: 8813.021350999999413033947349 when cast as a float.
Decimal types exists in many languages and databases. This type prefers accuracy over precision and thus 8813.021351 would remain the same.
However, the implementation of the decimal type can vary greatly.
Python:
In Python, this was the issue I was running into:
This module has some strange behaviours including this strange conversion when casting a decimal. It appears to convert the literal to a float and then decimal, causing the strangeness above.
The module does not show this behaviour if casting the decimal from a string:
There could be several reasons for this and I have researched quite a bit. In my opinion ,the reasoning is quite obtuse.
MySQL:
MySQL also has some strange behavior when using float or double type fields especially with more then 7 digits in either direction.
The decimal type in MySQL appears to work as one would expect and is the reason the experimental branch of the database loader has been created.
The integer solution:
One way of dealing with the float/decimal issue is to use the same method as the coin daemons. This method involves converting all numbers to integers of the smallest unit thereby using integer math exclusively.
The integers are then converted to their decimal equivalent when displayed to the user.
This goes against the principal of human readable databases that I have for CCE. Values are no longer truly human readable because all numerical values have to be converted to be read correctly.
Master branch implemented solution:
I used decimal types in the database. Whenever the database loader gets a numerical value from the database, it will double cast when necessary (String -> Decimal).
I wanted to avoid this solution as I do not like the idea of purposely miscasting a type to solve a computation issue. To me, it is a hacky solution, but it works well.
Against my better judgement, this is the solution implemented.
I am sure once the code becomes available on Github, somebody will have a better method for dealing with this.
Float types are designed for precision over accuracy.
A number like this: 8813.021351 , can turn out like: 8813.021350999999413033947349 when cast as a float.
Decimal types exists in many languages and databases. This type prefers accuracy over precision and thus 8813.021351 would remain the same.
However, the implementation of the decimal type can vary greatly.
Python:
In Python, this was the issue I was running into:
Code:
>>> from decimal import *
>>> txin = Decimal(8813.021351)
>>> print txin
8813.021350999999413033947349
>>> txout = Decimal(9813.021351)
>>> print txout
9813.021350999999413033947349
>>> print type(txin)
>>> print type(txout)
>>> txin = Decimal(8813.021351)
>>> print txin
8813.021350999999413033947349
>>> txout = Decimal(9813.021351)
>>> print txout
9813.021350999999413033947349
>>> print type(txin)
>>> print type(txout)
This module has some strange behaviours including this strange conversion when casting a decimal. It appears to convert the literal to a float and then decimal, causing the strangeness above.
The module does not show this behaviour if casting the decimal from a string:
Code:
>>> txin = Decimal(str(8813.021351))
>>> txout = Decimal(str(9813.021351))
>>> print txin
8813.021351
>>> print txout
9813.021351
>>> print type(txin)
>>> print type(txout)
>>> txout = Decimal(str(9813.021351))
>>> print txin
8813.021351
>>> print txout
9813.021351
>>> print type(txin)
>>> print type(txout)
There could be several reasons for this and I have researched quite a bit. In my opinion ,the reasoning is quite obtuse.
MySQL:
MySQL also has some strange behavior when using float or double type fields especially with more then 7 digits in either direction.
The decimal type in MySQL appears to work as one would expect and is the reason the experimental branch of the database loader has been created.
The integer solution:
One way of dealing with the float/decimal issue is to use the same method as the coin daemons. This method involves converting all numbers to integers of the smallest unit thereby using integer math exclusively.
The integers are then converted to their decimal equivalent when displayed to the user.
This goes against the principal of human readable databases that I have for CCE. Values are no longer truly human readable because all numerical values have to be converted to be read correctly.
Master branch implemented solution:
I used decimal types in the database. Whenever the database loader gets a numerical value from the database, it will double cast when necessary (String -> Decimal).
I wanted to avoid this solution as I do not like the idea of purposely miscasting a type to solve a computation issue. To me, it is a hacky solution, but it works well.
Against my better judgement, this is the solution implemented.
I am sure once the code becomes available on Github, somebody will have a better method for dealing with this.
Latest update on Open Source CCE 4.0
The latest revisions have been mostly dealing with float rounding issues.
The issue has now been dealt with and in the process a new experimental branch of the CCE 4.0 database loader has been started.
This new branch changes some of the fundamentals of the database loader, and has not been tested as much as the current CCE 3.0 - 4.0 database loader which has been on-line for a couple of years.
When the open source version goes up on Github, only the main branch will be available as I am now finishing it up and getting it ready for publication. Work on the experimental branch will continue once the main branch is published.
The experimental branch moves all the calculations to the database itself. The loader module only deals with some simple integer calculations.
The next post will contain a more detailed explanation of the problem and solutions.
The latest revisions have been mostly dealing with float rounding issues.
The issue has now been dealt with and in the process a new experimental branch of the CCE 4.0 database loader has been started.
This new branch changes some of the fundamentals of the database loader, and has not been tested as much as the current CCE 3.0 - 4.0 database loader which has been on-line for a couple of years.
When the open source version goes up on Github, only the main branch will be available as I am now finishing it up and getting it ready for publication. Work on the experimental branch will continue once the main branch is published.
The experimental branch moves all the calculations to the database itself. The loader module only deals with some simple integer calculations.
The next post will contain a more detailed explanation of the problem and solutions.
I have a question I need to pose to the users of POS chains.
When accounting for the number of transactions on an address, would you consider the address on a POS stake TX to have one or two transactions?
I can see it both ways.
Technically, it appears to be one transaction as it is one transaction hash.
However, the address is in both the TXIN and TXOUT in the transaction, so the argument can me made that it should count as two.
How do you think an explorer should count it?
When accounting for the number of transactions on an address, would you consider the address on a POS stake TX to have one or two transactions?
I can see it both ways.
Technically, it appears to be one transaction as it is one transaction hash.
However, the address is in both the TXIN and TXOUT in the transaction, so the argument can me made that it should count as two.
How do you think an explorer should count it?
A quick FYI:
The open source version of CCE 4.0 is very close to being released. I have decided to release a complete package including both the database loader and web server.
This will be a very basic version of CCE 4.0, some features will be added to this version (see README).
About a week ago, I took down the private git with an initial version of the database loader that I was showing to a few developers. This was in anticipation of the public release and the decision to release a complete basic explorer. The database loader has gone through a couple of revisions and some features have been removed. Some of these features will be added back in.
Anyway,
The official public repository is at : https://github.com/cryptocoinexplorer/Open-Source-CCE-4.0
At the moment, only the README is present.
The open source version of CCE 4.0 is very close to being released. I have decided to release a complete package including both the database loader and web server.
This will be a very basic version of CCE 4.0, some features will be added to this version (see README).
About a week ago, I took down the private git with an initial version of the database loader that I was showing to a few developers. This was in anticipation of the public release and the decision to release a complete basic explorer. The database loader has gone through a couple of revisions and some features have been removed. Some of these features will be added back in.
Anyway,
The official public repository is at : https://github.com/cryptocoinexplorer/Open-Source-CCE-4.0
At the moment, only the README is present.
Since board moderation deemed it necessary to lock the CCE 4.0 development thread, all CCE 4.0 development information will be here. 
The open source version of the CCE 4.0 database loader is at a release state. I have invited a few developers to have a look, and so far everything looks ok.
Tentatively I plan to release it at the same time the full production version of CCE 4.0 goes live.
However, I may release earlier.
The open source version of the CCE 4.0 database loader is at a release state. I have invited a few developers to have a look, and so far everything looks ok.
Tentatively I plan to release it at the same time the full production version of CCE 4.0 goes live.
However, I may release earlier.
Over the last month or so, there has been more downtime then normal. This is due to server restarts by the server provider.
Before the recent incidents, server restarts were a relatively rare occurrence.When CCE 3.5 was written last year, unattended restarts were not a major consideration.
I do not run a startup script for CCE servers as I prefer to manually restart CCE 3.5 explorers.
This is to ensure the startup goes smooth as there are a couple of issues, though rare, that could come up.
Development of CCE 4 started a few months ago and the database loader is at a state that it could be deployed.
The CCE 4 database loader is very restart friendly and also much more fault/error tolerant then the CCE 3.5 loader.
In light of these recent events, I am going to write a modified version of the CCE 4 database loader that will work with CCE 3.5 databases.
This will allow me to confidently use a server startup script to start the explorers unattended whenever there is a restart.
The plan is to have this deployed over the weekend/early next week.
The new database loader has been patched into all the explorers and restart tests were done over the last few days.
My apologies for any inconvenience this has caused.
Please see the CCE 4.0 development thread for more info: https://bitcointalksearch.org/topic/cryptocoin-explorer-version-40-development-announcement-922521
Before the recent incidents, server restarts were a relatively rare occurrence.When CCE 3.5 was written last year, unattended restarts were not a major consideration.
I do not run a startup script for CCE servers as I prefer to manually restart CCE 3.5 explorers.
This is to ensure the startup goes smooth as there are a couple of issues, though rare, that could come up.
Development of CCE 4 started a few months ago and the database loader is at a state that it could be deployed.
The CCE 4 database loader is very restart friendly and also much more fault/error tolerant then the CCE 3.5 loader.
In light of these recent events, I am going to write a modified version of the CCE 4 database loader that will work with CCE 3.5 databases.
This will allow me to confidently use a server startup script to start the explorers unattended whenever there is a restart.
The new database loader has been patched into all the explorers and restart tests were done over the last few days.
My apologies for any inconvenience this has caused.
If one has not reentered their address information by now, how important is it to the address owner? I have found a technique that would allow the reintegration of the old list, but it would wipe out any new entries not on the old database.However, with CCE 4 the database is being majorly redesigned including the way address claims are stored. I will set aside some time to try and reintegrate the old entries sometime this week.
A little background on the issue being discussed.
The original Hyperstake database was corrupted with orphan blocks deeper then the normal orphan check scan. This required a complete database rebuild to correct. Because of the way the database was structured, the address owner information needed to be manually reentered record by record. The Hyperstake community had been quite active in claiming addresses, and there were many entries. I did reenter the largest of address holders, however it only takes a minute for one to enter their information and I was working under the assumption that one would reclaim their addresses if they wanted to show up on the rich list.
Your answer is OK for me. A little background on the issue being discussed.
The original Hyperstake database was corrupted with orphan blocks deeper then the normal orphan check scan. This required a complete database rebuild to correct. Because of the way the database was structured, the address owner information needed to be manually reentered record by record. The Hyperstake community had been quite active in claiming addresses, and there were many entries. I did reenter the largest of address holders, however it only takes a minute for one to enter their information and I was working under the assumption that one would reclaim their addresses if they wanted to show up on the rich list.
Current coins on CCE:CryptoBuck
Bitbar
Kilocoin
Blakecoin
Photon
HoboNickels
Bottlecaps
Goldcoin
Why HyperStake is not mentionned (explorer)? When will you fix the database entries for claimed address gone AWOL?Bitbar
Kilocoin
Blakecoin
Photon
HoboNickels
Bottlecaps
Goldcoin
Simple oversight in the case of the former. Hyperstake has been added.
If one has not reentered their address information by now, how important is it to the address owner? I have found a technique that would allow the reintegration of the old list, but it would wipe out any new entries not on the old database.However, with CCE 4 the database is being majorly redesigned including the way address claims are stored. I will set aside some time to try and reintegrate the old entries sometime this week.
A little background on the issue being discussed.
The original Hyperstake database was corrupted with orphan blocks deeper then the normal orphan check scan. This required a complete database rebuild to correct. Because of the way the database was structured, the address owner information needed to be manually reentered record by record. The Hyperstake community had been quite active in claiming addresses, and there were many entries. I did reenter the largest of address holders, however it only takes a minute for one to enter their information and I was working under the assumption that one would reclaim their addresses if they wanted to show up on the rich list.
Current coins on CCE:CryptoBuck
Bitbar
Kilocoin
Blakecoin
Photon
HoboNickels
Bottlecaps
Goldcoin
Why HyperStake is not mentionned (explorer)? When will you fix the database entries for claimed address gone AWOL? Bitbar
Kilocoin
Blakecoin
Photon
HoboNickels
Bottlecaps
Goldcoin
This month starts the development stage of CCE 4.0.
CCE 4.0 will be a major rewrite of large portions of CCE 3.5.
Internal Goals:
Improve efficiency of database loading and sorting
Increase speed of the web server module.
Decrease size and improve database structure and indexes.
Tentative New/Modified Features:
Sponsor/Developer explorer customization. Sponsor/Developers will be able to change the look and feel of the explorer whenever they wish.
Attributes like background image, coin image, table elements (border,backgrounds and text), and button/hyper-link settings. Each page and table will be independently set.
The developer message box will be replaced with a whole developer/sponsor set page and explorer home page headline.
Ability to parse and display TX messages in chains that support it.
Add country of IP address in the coin daemon peers page. Removal of port display after IP address as it is not useful information.
Plain text list of IP addresses for easy cut/paste into configuration files.
Plain text display option for block,transaction, rich list, and ledger pages.
Table sorting options.
Add ABE compatible API alongside the current CCE API. Improve the output of some of the more complex data returns from the CCE API.
Graphing of certain statistics.
More features are being considered. If anybody has any requests for other features, please post here!
CCE 4.0 will be a major rewrite of large portions of CCE 3.5.
Internal Goals:
Improve efficiency of database loading and sorting
Increase speed of the web server module.
Decrease size and improve database structure and indexes.
Tentative New/Modified Features:
Sponsor/Developer explorer customization. Sponsor/Developers will be able to change the look and feel of the explorer whenever they wish.
Attributes like background image, coin image, table elements (border,backgrounds and text), and button/hyper-link settings. Each page and table will be independently set.
The developer message box will be replaced with a whole developer/sponsor set page and explorer home page headline.
Ability to parse and display TX messages in chains that support it.
Add country of IP address in the coin daemon peers page. Removal of port display after IP address as it is not useful information.
Plain text list of IP addresses for easy cut/paste into configuration files.
Plain text display option for block,transaction, rich list, and ledger pages.
Table sorting options.
Add ABE compatible API alongside the current CCE API. Improve the output of some of the more complex data returns from the CCE API.
Graphing of certain statistics.
More features are being considered. If anybody has any requests for other features, please post here!
Cryptocoin Explorer is one of the oldest alt-coin explorers still in operation. When started almost three years ago , it was based on ABE. Since the middle of last year, it is now run on the CCE explorer software platform that I wrote.
CCE is now at version 3.99 and development of version 4.0 has recently been announced. https://bitcointalksearch.org/topic/cryptocoin-explorer-version-40-development-announcement-922521
Coin developers and communities can sponsor their coins to have an explorer on CryptoCoinExplorer.com
Sponsorship includes the following:
Setup of a CCE3 explorer for the sponsored coin.
Hosting and maintenance of the explorer
Developers Box access key. Access regulated by some basic rules of conduct.
Use of the explorers coin daemon to use as a seed node through a custom altcointech.net address.
This extra address allows the use of the daemon as a seed node if the explorer gets moved to a new server, or at a future date the need to separate the services arises.
Please see the API page for a description of the API access that CCE3 provides. API Instructions
Please see the sponsorship page for more information: Sponsorship
Current coins on CCE:
Bitbar
Kilocoin
Blakecoin
Photon
HoboNickels
Bottlecaps
Goldcoin
Hyperstake
Hempcoin
Electron
*Note: I have switched to a self moderated thread to keep the thread clean and relevant. For example, having old posts about bug reports that have been fixed clutter the thread.
I have no desire to censor anything and appreciate all the feedback given. However, given the radical change in the environment of this forum over the last year, I will remove disruptive posts.
This does not mean negative posts, but posts that are trollish and serve no real purpose or criticism.
Jump to: