CryptoCoin Explorer - Coin Block Explorers.

[girafon]

The .99999 issue could be a rounding error or possibly due to odd blocks like:
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??

This is one transaction, with 2 outputs, nothing wrong here i'd say.

(and ... i'd bet i know where those are coming from, that 19.8 number appears frequently at a given trc pool)

some pools even use the "generation" transaction to "pay" miners, if i remember right, eligius did (still do?) that earlier to distribute rewards to miners.

[dreamwatcher]

The .99999 issue could be a rounding error or possibly due to odd blocks like:
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??

This is one transaction, with 2 outputs, nothing wrong here i'd say.

(and ... i guess where those are coming from, that 19.8 number appears frequently at a given trc pool)

some pools even use the "generation" transaction to "pay" miners, if i remember right, eligius did (still do?) that earlier to distribute rewards to miners.

You are correct, I misspoke(typed?).

I still find it odd in the sense that it is different from the normal generation, as I would think that a coin base transaction would be uniform with a system that has constant value as a mining reward.

I am curious if this would be due to a modified client, or something inherit to the official client itself?

I guess the question is academic as the blocks are being accepted and the transaction does equal the 20 TRC reward.

[girafon]

I still find it odd in the sense that it is different from the normal generation, as I would think that a coin base transaction would be uniform with a system that has constant value as a mining reward.

I guess the question is academic as the blocks are being accepted and the transaction does equal the 20 TRC reward.

I just had a quick look at official bitcoin wiki, and couldn't find an exact limit to the number of output addresses, only the total amount is written there.

Not sure if it must be strictly equal to the current awaited value, or if it could also be smaller (i guess not, that would break the whole economy magic i guess)

I am curious if this would be due to a modified client, or something inherit to the official client itself?

I think the poolmining software is probably responsible for the block construction, never heard about that kind of client modification, long ago, when i gave a try to eligius pool (as miners only interact with the pool's software ?).

There are probably mining pools that submit generated blocks to multiple remote nodes to ensure it's correctly spread, quickly. (p2pool maybe? just a wild guess, not sure)

[dreamwatcher]

OK,

Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.

Please keep giving me feedback, and thank you for pointing out the issues.

[crazy_rabbit]

OK,

Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.

Please keep giving me feedback, and thank you for pointing out the issues.

thanks!

[dreamwatcher]

Please keep giving me feedback, and thank you for pointing out the issues.

I might be wrong, but block numbers go from 0 to X and height goes from 1 to X+1. In other words, genesis block height is 1, not 0.

Attempting to check first 20 blocks for PPC results in server error:

http://www.cryptocoinexplorer.com:2750/chain/PPcoin?hi=19&count=20

Off topic, sort of - Any clue why LTC explorer frequently shows no address for newly generated coins?

http://explorer.litecoin.net/block/1e616de547a7624f818f53f575fa90b1a9d5d1048108b7fcfd81b7bd13af4b83

Genesis block height being 0 or 1 could be debated. Blockchain.info lists the height of the Genesis block as 0. Blockexplorer.com, which arguably is the largest implementation of ABE, does not  list height.
ABE (which the block explorers on my site are based on) count it as 0. I never saw a big reason to change it, but if enough people feel it should be 1 I can look into changing it.

I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.


As for LTC, that is a different beast altogether, I am glad somebody got the LTC explorer up again before I did. 

[Sunny King]

I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.

Get-work may be part of it, but be aware that PPC explorer is also experiencing creeping memory leakage.

For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.

Just letting you know to keep that in mind.

Please try keep an eye on the memory utilization and the pattern of its growth. I did sporadically experience swap errors and os shutdowns on the seed nodes as well which are running on some type of hosted virtual machines. Although I cannot confirm whether it's caused by memory exhaustion of ppcoin.

Other nodes I have seem to be running quite stable though.

[dreamwatcher]

The PPC Explorer has been upgraded

I have applied the previous modifications and some new modifications to the current version ABE to bring PPC explorer up to date.

Integrating and changing the newest version of ABE with the PPC modifications made more sense then patching the explorer based on an old version of ABE.

The above mentioned issue with the server error has been fixed, and I have cleaned up some of the display formats. For example, limiting difficulty display to 2 decimal places.



 

[dreamwatcher]

I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.

Get-work may be part of it, but be aware that PPC explorer is also experiencing creeping memory leakage.

For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.

Just letting you know to keep that in mind.

Please try keep an eye on the memory utilization and the pattern of its growth. I did sporadically experience swap errors and os shutdowns on the seed nodes as well which are running on some type of hosted virtual machines. Although I cannot confirm whether it's caused by memory exhaustion of ppcoin.

Other nodes I have seem to be running quite stable though.

Before I rebooted the server tonight, the usage was up to 7%.

My guess is that an object that both Get work and the routine the daemon uses to stay current may be the culprit.

I will look at the PPC code to add an extra pair of eyes searching for it.

I have spent about 30-40 hours on the I0coin code trying to figure out its similar issue and have really just come out with more questions than answers.

How much, if any, does PPC daemon memory cache in terms of TX or even blocks?

The Bitcoin Daemon also used a large amount of memory until the latest releases, I believe there was a change in the database among a couple of other things that drastically lowered its memory footprint. Perhaps looking at the latest code might spark some ideas.

[dreamwatcher]

If genesis block generated 50 TRC than value for "Outstanding" is 20 TRC less than total amount of coins generated.

http://www.cryptocoinexplorer.com:3750/chain/Terracoin?hi=19&count=20

Extra work = rename "Outstanding" to something more appropriate, like "Total coins"?

Fixed. The amount discrepancy  was a small last minute change that slipped placement in the live server code on the last code update.

After reviewing the blockexplorer.com, I see they changed the default label to "Total BTC", so I have changed the label to "Total TRC" on the TRC explorer.

I will fix the label on the PPC Explorer as well.

Thank you for bringing it up.

[coinotron]

I've added links from Coinotron's Statistics page, Solved TRC blocks to CRYPTOCOINEXPLORER.COM.

PS
Thanks for running this site.
200 TRC donation sent to your account

[dreamwatcher]

Thank you for your support Coinotron.

Just a quick observation for Sunny and the pool operators:

I set maxconnections to 8  and I have noticed a significant drop in the memory usage creep.  The PPC daemon has only increased to 3.8% since I made the max Connections change and rebooted the daemon.

Normally  I would have went from about 3.4% at reboot, to around 5% memory usage in that same period of time.

Hopefully this observation will help the pool operators and get Sunny one step closer to squashing this bug.


 

[coinotron]

Good to know. I will try it on next PPC restart.
ATM my workaround is to increase share difficulty. This decreases number of RPC getwork calls. It helped me to extend time span between restarts to 3 days.

[dreamwatcher]

Just an update, as of now the ppcoin daemon has only crept up to 3.9% of the memory whereas normally at this point it would be around 7% and most likely shutdown.

So the max connections set at 8, at the very least, appears to solve the issue with my particular use of the daemon.

[coinotron]

I restarted ppcoind 5 hours ago with maxconnections=8.
Memory usage looks promising It is at 75MB atm. After previous restarts ppcoind quickly reached 300-400MB.

[dreamwatcher]

HAPPY 20,000 BLOCKS PPCOIN

http://www.cryptocoinexplorer.com:2750/block/8da162835fd37c359f96dc20112768397d08897c9195138bee7e920912ee8c7a

[dreamwatcher]

New coin Freicoin has been added to the explorer

Due to the unique nature of  demurrage, further modification of the explorer is needed.

I will keep you posted in this thread.

Good Luck Freicoin...You have some competition in the Alt-coin world. But I try to support as many as I can.  

[Sunny King]

Geez you are getting quite efficient with adding new coin support 

[dreamwatcher]

New coin Freicoin has been added to the explorer

Due to the unique nature of  demurrage, further modification of the explorer is needed.

WARNING: THE ADDRESS PAGE DOES NOT TAKE DEMURRAGE INTO ACCOUNT WHEN CALCULATING BALANCES
This is also causing issues with fee calculation when older coins are in the transfer, especially noticeable with large transfers

We are working on a solution, until then you can view the demurrage wikki at:

How-to-properly-handle-demurrage-in-applications

I will keep you posted in this thread.

I want to thank Maaku for his support in helping to further the functionality of the explorer.

TODO LIST:

1. Calculate demurrage in the address page
2. Related to #1, fix fee calculation to address demurrage

[dreamwatcher]

Terracoin part of explorer is not working for me in most cases.

Thank you for letting me know.

It appears a new set of exceptions concerning its connection with the database are starting to pop-up.

I will look onto this is issue and get it it fixed as quickly as possible.