Might I suggest cloud hosting, depending on the nature of the current speific issue. Cloud hosting can help with specific data center server issues.
"Cloud hosting" is essentially just a synonym to "data center"... W/e you wana call it or however you want to look at it... assuming this current issue is server specific and not he center as a whole. With cloud hosting, the pool would have already been mounted over a stable server and still be running. |
|
|
|
Mining server unreachable at the moment. Other things than Bitminter are down at the same data center, so I believe it is a data center issue. I have contacted them about this and it is being worked on.
Apologies for the downtime.
Might I suggest cloud hosting, depending on the nature of the current speific issue. Cloud hosting can help with specific data center server issues. |
|
|
|
|
I know shit happens and I livee with it so this isnt a complain, bu tfor rhte people with sticks up their ass. If whatever is wrong keeps happening, it will kill the pool inside of 60 days when a lot of the new equipment is out hat would help the pool.
|
|
|
|
|
[2014-01-02 17:29:51] Stratum connection to pool 0 interrupted
[2014-01-02 17:29:51] Lost 1 shares due to stratum disconnect on pool 0
[2014-01-02 17:29:53] Pool 0 stratum+tcp://mint.bitminter.com:3333 not responding!
[2014-01-02 17:30:01] Waiting for work to be available from pools.
|
|
|
|
I'd raher host the info on my own site so not as to rely on other parties by means of scraping data or w/e. I assume once I install w/e dependenies I need aside from the Qt4 libraries, that the following page (/full_path/bitcoin-node/src/INSTALL) will display more than just this... Building Bitcoin See doc/readme-qt.rst for instructions on building Bitcoin-Qt, the intended-for-end-users, nice-graphical-interface, reference implementation of Bitcoin. See doc/build-*.txt for instructions on building bitcoind, the intended-for-services, no-graphical-interface, reference implementation of Bitcoin. Either way, like I said... I know next to nothing about linux and installing dpendencies for programs. So even forgetting the data I want to pull. Just getting this thing going and start downloading the blockchain will take me a while assuming I ever can get it goin which is likely to never happen on my own unless someone whos done this before can quite literally hold my hand and walk me through it. |
|
|
|
Ok, so I was looking in to this more and I should be able to pull it off myself but it seems the full node software on bitcoin.org requires Qt4. So with that said where can I get the Qt4 runtime libraries for a CentOS distribution ? root@server [~]# cat /proc/version Linux version 2.6.32-358.18.1.el6.x86_64 ( mockbuild@c6b10.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Wed Aug 28 17:19:38 UTC 2013 root@server [~]# cat /etc/redhat-release
CentOS release 6.5 (Final)
It's very simple: - the daemon process is bitcoind. You'll find in the bin subdirectory right alongside -qt - bitcoind does NOT require a GUI. It's command line only. - You connect to bitcoind via jsonrpc. This is easily done in PHP. Use the getinfo commmand to get the latest difficulty stats. - the hardest problem is the resource requirements of bitcoind/-qt. Both require a complete download of the blockchain, meaning gigs of disk space, and they use up quite a bit of ram - at least 512MB. I suggest bootstraping bitcoind using the torrent download or it'll take forever to download and verify the blockchain. You'll find the torrent in the sourceforge repo. My knowledge of linux is so limited I'd screw things up trying to make sense of what you said, I would also prefer the GUI version over the command line one just for ease of use if I ever needed to get in to check, modify or upgrade something. It seems the GUI version is the one that needs the Qt4 livraries. That said, I have the ram and disskapce isn't an issue, last check the blockchain was something under 13gb and I have a hair over 20 available. Basically all I have done so far is just download the linux version of Bitcoin-Qt from bitcoin.org and uploaded it to one of my websites folders. Edit: FWIW, I wouldnt be looking to try and mine on my cloud, just host the full node to grav the info like current, next est difficulty and the block count til next increse like bitcoincharts.com has. |
|
|
|
Ok, so I was looking in to this more and I should be able to pull it off myself but it seems the full node software on bitcoin.org requires Qt4. So with that said where can I get the Qt4 runtime libraries for a CentOS distribution ? root@server [~]# cat /proc/version Linux version 2.6.32-358.18.1.el6.x86_64 ( mockbuild@c6b10.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Wed Aug 28 17:19:38 UTC 2013 root@server [~]# cat /etc/redhat-release
CentOS release 6.5 (Final)
|
|
|
|
Whatever you mine with, you'll never make back the amount of btc you spend to buy the miner.
I wouldnt go that far, it's possible, all be it more improbable. There's a lot of factors that could easily come in to play to make it more than possible. |
|
|
|
|
[2013-12-31 19:18:53] Stratum connection to pool 0 interrupted
[2013-12-31 19:18:53] Lost 6 shares due to stratum disconnect on pool 0
[2013-12-31 19:18:54] Pool 0 stratum+tcp://mint.bitminter.com:3333 not respond
ng!
[2013-12-31 19:19:03] Waiting for work to be available from pools.
|
|
|
|
|
I'd like to see he pool survive bu no sure if it will now...
last_month last_week last_day last_hour last_5_min
27094.235 19630.003 7967.795 6337.613 5650.846
|
|
|
|
What does it take to run this pool, you make eit sound like a bad investment but the one HHTT payment address at last checked showed over 80+ BTC in it. As long as the pool finds 4 blocks month, what you as the operator gets out of those four should b more than enough to run the server it's on I'd imagine.
As for merged mining, I say give it a shot beause at this point it couldnt hurt.
Have you not looked at the total history? Total loss of > 818BTC No, but I just did a check, Final Balance 98.0948075 BTC at current BTC-e prices the pool has a current value of $68,600 assuming $700 per BTC. I'm still curious though just how "bad" it could be to host the pool on w/e server it's on. I gota cloud VPS with 70+gb of space a decen number of CPU cores and available memory and it cost me $100 a month. I don't pretend to know what it costs to host a pool but even on a $200 a month server, that's easily made as a pool opp with ducks settings and assuming a minimum of four bloks a month found |
|
|
|
|
What does it take to run this pool, you make eit sound like a bad investment but the one HHTT payment address at last checked showed over 80+ BTC in it. As long as the pool finds 4 blocks month, what you as the operator gets out of those four should b more than enough to run the server it's on I'd imagine.
As for merged mining, I say give it a shot beause at this point it couldnt hurt.
|
|
|
|
In addition to he above...
In hindsight, why would the bitcoincharts people have suggested github when I just found out the official software from bitcoin.org is bitcoin-qt ?
Besides that, I downloaded it from bicoin.org but am now at a loss as to how to install it and run it so it can beggin to download the blockchain.
Because the official source code repository is at github. So if you want to see the official source you can. He was being helpful  Ahh, well... I ha a look at the DL from the bitcoin.org site, chose the linux package because that's what my Cloud VPS is running with cPanel. In any event, I'm at one hell of a loss... looks like I'll never get this done unless I fork over some cash to someone trustworthy enough to muck around on my server. |
|
|
|
|
In addition to he above...
In hindsight, why would the bitcoincharts people have suggested github when I just found out the official software from bitcoin.org is bitcoin-qt ?
Besides that, I downloaded it from bicoin.org but am now at a loss as to how to install it and run it so it can beggin to download the blockchain.
|
|
|
|
A basic estimate, which I believe Bitcoincharts also uses, is to simply estimate the next difficulty based on the time spent on mining since the last diff change.
Suppose we're N blocks past the previous difficulty adjustment, and a time T (in seconds) has passed since the previous adjustment. The average time per block so far has been T / N. The target rate is 600 seconds per block and if during a period of 2016 blocks the generation rate was X% higher than that, the difficulty is adjusted upwards by X%. So you compute 600 / (T / N) = 600 N / T and you obtain the multiplier to predict the next difficulty.
Not quite the help I was looking for but ty, there has to be more than random guessing to the next est. I say this because for two sites to use ehe same "random" math to guess the next est is not likely to happen. http://www.bitcoindifficulty.com/Has the same current and next est figures, except bicoincharts also has the in x blocks thing. It's far from random to compute the estimate this way. It's the most obvious way to estimate it and as the difficulty adjustment moves closer, the prediction becomes more accurate. The "in XYZ blocks" statistic of bitcoincharts isn't an estimate, it's fully accurate since difficulty adjustments happen every 2016 blocks, it's easy to calculate how many blocks are left to the next jump. Bitcoindifficulty.com simply doesn't show this number. In any case, I apparently still need some bitcoin software or something on my VPS to at the very least grab current diff and the in x blocks figure. That's where I go duuuh and drool. I have the percentage code and everything else worked out. if($context['user']['is_admin']){
$current_diff = 1180923195;
$next_est_diff = 1344959376;
if($next_est_diff >= $current_diff){
$diff_percent = '+';
$inc_or_dec = 'Increase';
}else{
$inc_or_dec = 'Decrease';
}
$diff_percent2 = $next_est_diff - $current_diff;
$diff_percent3 = $diff_percent2 / $current_diff;
$diff_percent4 = $diff_percent3 * 100;
echo '
<br />
Current Difficulty: '.number_format($current_diff).'<br />
Next Difficulty (Est.): '.number_format($next_est_diff).'<br />
'.$inc_or_dec.' by: '.number_format(abs($diff_percent2)).' ('.$diff_percent.''.number_format($diff_percent4, 2).'%)<br />
<font style="font-size: 11px;">(Next increase in 0,000 blocks.)</font>
';
}
Which displays this right now... mind you when the bioin stuff is addd, i would all change automatically when changes are detected in whatever bitoin stuff I need to install. Current Difficulty: 1,180,923,195 Next Difficulty (Est.): 1,344,959,376 Increase by: 164,036,181 (+13.89%) (Next increase in 0,000 blocks.) |
|
|
|
A basic estimate, which I believe Bitcoincharts also uses, is to simply estimate the next difficulty based on the time spent on mining since the last diff change.
Suppose we're N blocks past the previous difficulty adjustment, and a time T (in seconds) has passed since the previous adjustment. The average time per block so far has been T / N. The target rate is 600 seconds per block and if during a period of 2016 blocks the generation rate was X% higher than that, the difficulty is adjusted upwards by X%. So you compute 600 / (T / N) = 600 N / T and you obtain the multiplier to predict the next difficulty.
Not quite the help I was looking for but ty, there has to be more than random guessing to the next est. I say this because for two sites to use ehe same "random" math to guess the next est is not likely to happen. http://www.bitcoindifficulty.com/Has the same current and next est figures, except bicoincharts also has the in x blocks thing. |
|
|
|
Ok, so first check out this site: http://bitcoincharts.com/Notice the following top left ? Difficulty 1,180,923,195 Estimated 1,344,395,037 in 765 blks Well, I asked the staff of that site if they could tell me the code used to produce this info and this is the reply I got. It's the same algorithm used in bitcoin-qt to calculate the next
difficulty. You can find bitcoin-qt's source code on github.
So I looked on github and found a lot of things mentioning bitcoin-qt. Anyway, as to the reason I am here... If anyone can help me get this info displayed on the sites of mine I'd like it dpsplayed on without having it scraped from an existing site even if it means me hosting some bicoin client on my server I'd greatly appreciate it, Ty. |
|
|
|
% increase = (next_est - current) / current * 100.
As pointed out it is rounded, it is an estimate, even 14% has a significant margin of error putting extra digits is just noise.
For the record the % increase of anything = (new - old) / old * 100
Ty, knew it had to be something simple in the calculations. Working fine on my site now. |
|
|
|
Current: 1,180,923,195 Next (Estimate): 1,345,007,299 (+14%) Increase by: 164,084,104 Taken from: http://www.bitcoindifficulty.com/If the increase estimate was truly 14% it (the increase by) should be around 165,329,247 Mind you when it (next est) was about 60k less, it still showed 14%... I was wondering if anyone might be able to help figure out what the math used that gets them their % increase figure. Best I can tell is they use two diff bits of code that are slightly out of sync with eachoher hence the percentage not being quite right. This is what I came up with as suggested math after a yahoo search but it's not even anywhere close ;-/ current / next est * 100 = 87.80% The 14% value you mention is rounded. A more precise estimate of the percentage-increase using the numbers you provided is 13.89%, which indeed rounds to 14%. Since difficulty-estimates are typically rather inaccurage, specifying more than 2 significant digits in the percentage-increase is not necessary. But my question is whats the math used to ge the 14%, I know it's probably staring me right in he face but I'm not seeing it. I'm working on something for one of my sites but the math to get the percentage is eluding me. |
|
|
|
Current: 1,180,923,195 Next (Estimate): 1,345,007,299 (+14%) Increase by: 164,084,104 Taken from: http://www.bitcoindifficulty.com/If the increase estimate was truly 14% it (the increase by) should be around 165,329,247 Mind you when it (next est) was about 60k less, it still showed 14%... I was wondering if anyone might be able to help figure out what the math used that gets them their % increase figure. Best I can tell is they use two diff bits of code that are slightly out of sync with eachoher hence the percentage not being quite right. This is what I came up with as suggested math after a yahoo search but it's not even anywhere close ;-/ current / next est * 100 = 87.80% |
|
|
|
|
Show Posts
