CoinChoose - alternative site to show respective profitability of the alt coins

[sal002]

ok. i see what u mean. thats not easy.


btw, craftcoin gone on your side...

Blockexplorers are down for several coins.

^^^^
||||||||

[1714994709]

1714994709

[1714994709]

1714994709

[sal002]

Sal - do you have a timeline as to when http://www.coinchoose.com/jsondata.php?hours=X will be fixed? Thanks for your amazing work on this!

Fixed.  Mind you I only keep up to 18 days of data.

[baritus]

How come DGC was gone for a few hours?

[sal002]

How come DGC was gone for a few hours?

Cryptocoinexplorer block explorers went down (one server did).  Took out all coins associated with that block explorer as I have my settings to remove a coin if the data gets stale.

[ISAWHIM]

If you are using API, you should get the information for "1BTC" worth of trades, at minimum, from the "buying" list, for the value estimates. Since miners are here to "Sell to the buyers" and since the estimations are for 1BTC for comparison.

Eg, if there is 0.0001coin/btc-val being sold for 0.001BTC, that is useless to use for estimation. However, if you "sold all now" to obtain 1BTC, thus, you would have to take the values of 0.0001 and 0.000099 and 0.000095 and 0.000081 and the last value of 0.000065. Thus, the "actual value" of the "volume of trades", for that estimated 1BTC earning, NOW... would be more realistically something like 0.000075 not the horribly inaccurate 0.000100 used for the calculation.

Since, in reality, anyone can manipulate the market earnings up or down with 0.00001 buys and sells... which are a false indication of actual "sell value".

To be more accurate to the coin... If the coins "adjusted earnings" are 0.5 BTC per day... You might want to use a total of 10BTC worth of buy-listings. (Daily earnings in coin x, multiplied by 20 miners cash-out-now volume.) That would also help reduce the pumping, purposely done to get more people to mine a coin with an artificial inflated micro-change value. Which is also done to attempt to get people to list higher values for a big dump of coins they got cheaper, previously in a trade or sale or mining.

Also... you need to use real-world values for things like, "Stales and rejects". Not sure where you are getting your information from for those numbers, but no coin is ever 100%. If you see that calculated value, you might as well just assume the source of your info is not sending you actual data, and just sending you the mined-data twice. Thus, that should be for that column. If you used real-world data from a pool or from some miners... and kept a record of those numbers for viewing... It would be better for us to make judgement. However, seeing that there is 0% loss, or only 5% loss, then mining for hours, only to find that the loss is 50% or more... only discredits you and your use of poor source information that you are feeding us.

(Also, stales are predictable at certain diff-levels, with certain hash-rates worth of miners. Even if you just used that ratio-value, you would be offering a better estimation of reality. Especially on these fast-coins that have 30-sec to 1-min blocks, when they suddenly get 500Mhs thrown at them. You can see what the movement is, and you know what the result is, it isn't hard to calculate what the losses will be, before you post the "estimated value" and losses. At the least, you will be wrong, in our favor, if the losses are less. At the moment, they losses are all against us, since they are all inaccurate and low, compared to reality. A dedicated miner has no use for this info, thus, would never be hurt by it. But directing people there, with the auto-switcher miner, places all the trust and accuracy on you and your sources of data and representation of that data, which they use to mine.)

Great site.

P.S. If a coin is "down", could you just move it to a section below, marked as "block down, insufficient data for listing". Just so that we know you have not completely and permanently removed it from the listing.

[sal002]

If you are using API, you should get the information for "1BTC" worth of trades, at minimum, from the "buying" list, for the value estimates. Since miners are here to "Sell to the buyers" and since the estimations are for 1BTC for comparison.

Eg, if there is 0.0001coin/btc-val being sold for 0.001BTC, that is useless to use for estimation. However, if you "sold all now" to obtain 1BTC, thus, you would have to take the values of 0.0001 and 0.000099 and 0.000095 and 0.000081 and the last value of 0.000065. Thus, the "actual value" of the "volume of trades", for that estimated 1BTC earning, NOW... would be more realistically something like 0.000075 not the horribly inaccurate 0.000100 used for the calculation.

Since, in reality, anyone can manipulate the market earnings up or down with 0.00001 buys and sells... which are a false indication of actual "sell value".

To be more accurate to the coin... If the coins "adjusted earnings" are 0.5 BTC per day... You might want to use a total of 10BTC worth of buy-listings. (Daily earnings in coin x, multiplied by 20 miners cash-out-now volume.) That would also help reduce the pumping, purposely done to get more people to mine a coin with an artificial inflated micro-change value. Which is also done to attempt to get people to list higher values for a big dump of coins they got cheaper, previously in a trade or sale or mining.

I think that is a good idea, which is why I am already doing it (just not to the extreme you are asking). Right now the manipulation of pricing is tough with small orders - I do have a minimal order size (at least several blocks of the coin), really look at the depth of the market  and use a weighted average to get to a set depth from the exchanges I can get the depth, but 1BTC might be a bit big (many of these alt coins don't hit that in a thousand blocks).  I may just add another column that has a deeper price (so the users can choose).  I also only look at the buying side, not the selling side, because those are the orders available for converting the alt coin into BTC / LTC.  I am already doing partially what you are asking, just not at the 1 BTC level yet as I think in many coins that is unrealistic.

The whole stale calc was based off some prior analysis and a derived formula from that analysis to anticipate stales- real world stats would be great, but really not available unless I hired someone to have a full-time job getting data from all pools for all these alt-coins.  As far as the 100%, you gotta realize this is 100% compared to BTC - which means the coin is anticipated to have the same stale rate as BTC.  I guess the alternative is to remove the stat and if others agree, I will remove it since, as you say, it discredits my whole site.  I just can't get the real world stale stats from every pool out there as pools come and go, most pools do not make the info readily accessible and I miss stats from solo mining.  

[ISAWHIM]

For stales, you only need to query any miners API and get the A: (accepted values) and R: (Rejected values) and get the network-hash-rate. (Solo miners or a pools wallet) Once you KNOW the saturation of each diff/hash then the rest can be calculated and estimated, also knowing the result of oversaturation.

Though, with a diff of 0.16 and a 10Mhs worth of miners... there may not be any. (That is an ideal load)
With a diff of 0.16 and 300Mhs now mining, because you indicate exchange value high... there may be 25% rejects. (Thus, you can display that "anticipated" value, if that is the load that normally moves there, when you say move-there. Or, you can adjust on the next round, once they have moved there.)

The rejects never changes, for that diff at that hash-rate. However...
at 2.4 diff, with the same 300Mhs, there may only be 3% rejects, because the network is not saturated. Thus, you will not know the saturation point of that 2.4 diff, until you move 600Mhs there.

In the end, each diff-level from low->high is only needed, to determine the saturation point, and the expected losses with x-hash-rate of miners now mining it. (But confirmed real-world values would be more accurate.)

Again, you don't have to hire anyone. Just have us list our wallets API access, or for pools (much better), ask for API access to that info. They can provide a page that only output that data in HTML in CSV format, for simplicity. Labor-force = 0.

The flaw is with the coin itself. Poor programming for saturation, due to fast-blocks and poor network load control using diffs that just jump all over, too fast, too high, and drop too fast, too low. This is hardly an issue for slower coins, because they adjust before saturation occurs, and with the large number of constant miners, the move of 300Mhs to a 30Ghs coin, is less dramatic. However, moving 300Mhs to a coin that only has 10Khs of constant miners, leads to saw-tooth coin death. lol. Diff 2.44, diff 0.16, diff 2.44, diff 0.16, ... value 75%btc, 180%btc, 75%btc, 180%btc... as the miners jump in and out, degrading the coin they "think" has high value, turning it into that "low-value" coin.

If a coin does not have 1btc of "buying" listings... then it is not worth listing, or mining. Because there is no-one to sell it to! Thus, the value on the charts should be lower...

[sal002]

For stales, you only need to query any miners API and get the A: (accepted values) and R: (Rejected values) and get the network-hash-rate. (Solo miners or a pools wallet) Once you KNOW the saturation of each diff/hash then the rest can be calculated and estimated, also knowing the result of oversaturation.

Though, with a diff of 0.16 and a 10Mhs worth of miners... there may not be any. (That is an ideal load)
With a diff of 0.16 and 300Mhs now mining, because you indicate exchange value high... there may be 25% rejects. (Thus, you can display that "anticipated" value, if that is the load that normally moves there, when you say move-there. Or, you can adjust on the next round, once they have moved there.)

The rejects never changes, for that diff at that hash-rate. However...
at 2.4 diff, with the same 300Mhs, there may only be 3% rejects, because the network is not saturated. Thus, you will not know the saturation point of that 2.4 diff, until you move 600Mhs there.

In the end, each diff-level from low->high is only needed, to determine the saturation point, and the expected losses with x-hash-rate of miners now mining it. (But confirmed real-world values would be more accurate.)

Again, you don't have to hire anyone. Just have us list our wallets API access, or for pools (much better), ask for API access to that info. They can provide a page that only output that data in HTML in CSV format, for simplicity. Labor-force = 0.

The flaw is with the coin itself. Poor programming for saturation, due to fast-blocks and poor network load control using diffs that just jump all over, too fast, too high, and drop too fast, too low. This is hardly an issue for slower coins, because they adjust before saturation occurs, and with the large number of constant miners, the move of 300Mhs to a 30Ghs coin, is less dramatic. However, moving 300Mhs to a coin that only has 10Khs of constant miners, leads to saw-tooth coin death. lol. Diff 2.44, diff 0.16, diff 2.44, diff 0.16, ... value 75%btc, 180%btc, 75%btc, 180%btc... as the miners jump in and out, degrading the coin they "think" has high value, turning it into that "low-value" coin.

If a coin does not have 1btc of "buying" listings... then it is not worth listing, or mining. Because there is no-one to sell it to! Thus, the value on the charts should be lower...

I will take a look.  Last I did I couldn't see an API that presented the info - nor an ideal way to auto add new pools as they add and go.  I will see if that is fixed and if there is some way for a given coin to automate getting a list of all pools and getting the stale and rejected rates.  If you know of any API's for all of these pools, please let me now. 

I understand your point, but I disagree about the 1BTC limit.  If we do that, the price gets too skewed to be too low because then, in many markets, you have the really low orders that never really get executed (and wouldn't in the course of mine and selling the coin).  My opinion is 1BTC is unrealistic as, I mentioned, most of the coins never hit that 1BTC depth in an efficient scheme of mining and selling.  I think this will take a lot more analysis, but I have at least addressed the issue of not skewing with small orders already.

But then, I can say that the depth is not 1BTC, and if you feel that is unrealistic to look at a shallower depth, then you can safely ignore my site   I may put up a FAQ page so these points are clear and the users can make educated decisions about whether to rely on the site or not. 

[sal002]

Again, you don't have to hire anyone. Just have us list our wallets API access, or for pools (much better), ask for API access to that info. They can provide a page that only output that data in HTML in CSV format, for simplicity. Labor-force = 0.

Maybe I am misreading - can I already get this from my coin client?  I thought I couldn't.  As far as the pools - do you know what pools have this info already available?  I guess it will take some modification to one of the source code for the pools so that when new pools pop up they already have this info available. 

Too many things to do and just not enough time.  Your points are valid, but afraid, unsolvable in an efficient way without massive effort and coordination among ALL cryptocurrency pools, in my opinion.  Open to suggestions for other ways to get this data via readily available methods.

[ISAWHIM]

Best way is to mine all coins you list. Thus you have first-hand knowledge of the data, not second-hand.

I repeat... lol... this is less of an issue with slow-block coins. It is only the less populated faster coins, where the percents are waaaay off. Making them look a lot more valuable to mine, then they really are in reality.
MNC, WDC, FST, LKY, DGC, MEG, MEM, BBQ... etc...

As for pools that do this already... Most pools have an API, they just have to add that accepted/rejected value to the list of available data. Ask, they will add it, if it brings them more miners. They may want a mention of the pool. (Eg, Stats provided by "www.somepool.com" for "MNC". When people click on the data % values, to see where you get your numbers from. Like when they click the links to the exchanges.)

This is my 4-days worth of mining "CAP" "Bottlecaps"...

Using one of my machines, mining @ 3Mhs (6x 7970's running stock about 500Khs/ea) 3200 CAP coins
A: 46, R: 13
A: 40, R: 12
A: 48, R: 14
A: 31, R: 23
A: 54, R: 12
A: 49, R: 14

Totals
A: 268, R: 88 = 356 submitted
100%/356 = 0.280899
268*0.280899 = 75% Accepted / 25% Rejected

Thus, Your 178.87% Profit should be, 178.87%*0.75 = "134.15% Profit adjusted for stales", not 178.87% which would be 100% accepted and 0% rejected.

[toruonu]

The coinchoose website shows BTC and LTC profitability tables. However it seems the API only returns the BTC comparison and not the LTC one and for coins that only have LTC market this means that they're simply not there.

Is there some way to also get the LTC table in some computer parsable format?

[sal002]

Best way is to mine all coins you list. Thus you have first-hand knowledge of the data, not second-hand.

I repeat... lol... this is less of an issue with slow-block coins. It is only the less populated faster coins, where the percents are waaaay off. Making them look a lot more valuable to mine, then they really are in reality.
MNC, WDC, FST, LKY, DGC, MEG, MEM, BBQ... etc...

As for pools that do this already... Most pools have an API, they just have to add that accepted/rejected value to the list of available data. Ask, they will add it, if it brings them more miners. They may want a mention of the pool. (Eg, Stats provided by "www.somepool.com" for "MNC". When people click on the data % values, to see where you get your numbers from. Like when they click the links to the exchanges.)

This is my 4-days worth of mining "CAP" "Bottlecaps"...

Using one of my machines, mining @ 3Mhs (6x 7970's running stock about 500Khs/ea) 3200 CAP coins
A: 46, R: 13
A: 40, R: 12
A: 48, R: 14
A: 31, R: 23
A: 54, R: 12
A: 49, R: 14

Totals
A: 268, R: 88 = 356 submitted
100%/356 = 0.280899
268*0.280899 = 75% Accepted / 25% Rejected

Thus, Your 178.87% Profit should be, 178.87%*0.75 = "134.15% Profit adjusted for stales", not 178.87% which would be 100% accepted and 0% rejected.

I don't have the bandwidth nor the resources to mine every coin I list as that would take a lot of mining hardware.  Is your ultimate suggestion that I just shut down the site as it is misleading?

Maybe I can work in a mechanism where the users of the site submit the pools they are using?  The first issue is identifying all the pool sites and then convincing each of those pools to add in the extra data (and still not sure how to handle the pools that refuse - maybe delist the entire coin if one major pool for a given coin refuses to give the data)? 

That being said - you have hit on a portion of my formula already - faster block coins DO have a lower adjusted profitability on my site.

[sal002]

The coinchoose website shows BTC and LTC profitability tables. However it seems the API only returns the BTC comparison and not the LTC one and for coins that only have LTC market this means that they're simply not there.

Is there some way to also get the LTC table in some computer parsable format?

http://www.coinchoose.com/api.php?base=ltc

Sorry - I need to add this back on the site - but it should work!

[sal002]

Best way is to mine all coins you list. Thus you have first-hand knowledge of the data, not second-hand.

I repeat... lol... this is less of an issue with slow-block coins. It is only the less populated faster coins, where the percents are waaaay off. Making them look a lot more valuable to mine, then they really are in reality.
MNC, WDC, FST, LKY, DGC, MEG, MEM, BBQ... etc...

....

This is my 4-days worth of mining "CAP" "Bottlecaps"...

Using one of my machines, mining @ 3Mhs (6x 7970's running stock about 500Khs/ea) 3200 CAP coins
A: 46, R: 13
A: 40, R: 12
A: 48, R: 14
A: 31, R: 23
A: 54, R: 12
A: 49, R: 14

Totals
A: 268, R: 88 = 356 submitted
100%/356 = 0.280899
268*0.280899 = 75% Accepted / 25% Rejected

Thus, Your 178.87% Profit should be, 178.87%*0.75 = "134.15% Profit adjusted for stales", not 178.87% which would be 100% accepted and 0% rejected.

CAP is not a fast block coin (compared to BTC).  Any thoughts as to why so many stales?  Also - this is not true "which would be 100% accepted and 0% rejected.".  178.87% would be the same rates accepted / rejected as BTC.  But I have CAP as the same blocks per minute as BTC - perhaps that is wrong.

[captainfuture]

sal, any plans of adding primecoin in future? its traded on e-coins already.

btw, u cant do it right for everyone, so thanx for your work and keep on going  

perhaps it would be nice to get a column with more depth (at least 1 btc), i dont know. its up to you and u will do it right  

[sal002]

sal, any plans of adding primecoin in future? its traded on e-coins already.

btw, u cant do it right for everyone, so thanx for your work and keep on going  

perhaps it would be nice to get a column with more depth (at least 1 btc), i dont know. its up to you and u will do it right  

That may be a good idea - give more info and allow the users to choose.

As far as Primecoin - is there a block explorer?

[John Eden]

Sal any way to update the CAP icon on coinchoose.

[sal002]

Sal any way to update the CAP icon on coinchoose.

Sure - is the icon in your profile the right one?

[digitalindustry]

Sal any way to update the CAP icon on coinchoose.

Sure - is the icon in your profile the right one?

if you go back about 2 pages I actually include one - but i thought you might have either missed it or thought that i was trying to hijack the process  : D

I have the original here , but all that aside...



Sal i think you are doing a great job - guys , this would be a lot of work to keep this site up to date like this , this Site is user optional , so Ishwhim if you have lot of good suggestions , perhaps you can help Sal implement them ?

I took a step back regarding the Sawtooth zig zag of difficulty, explain how this is a problem and leads to "Currency death"?  this is just a volatile market.

if the currency has any merit , this Sawtooth will become a Wave and then a Trend.

if the Currency has no value then the Saw tooth will continue and the Devs will walk away or get passed on .

all this to me is just natural ?, but i do notice how a Dev will try to Hard fork for difficulty , the only reason to hard fork is for Security or innovation, if your currency is insecure at low hash then , it was probably not that viable in the first place.   

[sal002]

Oops - slipped my mind.  I will use that one shortly.

Thanks for the encouragement.  I run this site part-time and it is just enough to keep up with new currencies / exchanges to occupy my time.  I'd love to coordinate the effort to get info from all pools, but just lack time.  Looking for volunteers