I saw that, but I think it involves changing the code of poclbm? While doable, it would be a nuisance if new versions of poclbm appear and the modifications had to be repeated.
Do you know how to use git? You can make a modification in your copy and each time m0mchill changes poclbm, you simply pull git changes and if it does not conflict with your version, the changes apply without any fuss. This is a very convenient and standard way of keeping a fork of a program up to date. |
|
|
|
The problem with that is when you login via ssh not all features of aticonfig work (they only work properly if you're using it directly from the machine which has the screen connected). I am sure Raulo will be able to shed some light here.  Everything works exactly the same with ssh as it works via console if you have DISPLAY=:0 set and you are the user that "owns" the display. If the latter is not fulfilled, being root and having DISPLAY=:0 is all you need. |
|
|
|
|
Anybody who claims to know what will happen on the market is either a fool or tries to pump the value of his holdings (that's why there is consistent bullish bias everywhere on the stock market). Or both.
|
|
|
|
It does absolutely not make sense timing bringing up capacity online. The most optimal strategy is to mine as soon as possible. A mined block is worth more than the loss resulting from difficulty increase of one's mining in the next round.
That would depend on how much computing power you were going to bring online and how long till the next difficulty increase. No, it's not unless we are talking about some crazy scenarios that someone increases the difficulty by so much (say 20-fold) that next round mining brings less income than electricity. Each block you mine in the round n will lower your mining output by 1/2016*(your_hash_speed_next_round/global_hash_speed_next_round)*2016=(your_hash_speed_next_round/global_hash_speed_next_round) in round n+1 due to difficulty increase resulting from getting this particular block sooner. And this number is always less than 1 because your hash speed is lower than the global hash speed. So it is always (without taking into account electricity costs) worth mining a block without worrying about the next difficulty increase. In a less abstract example, suppose, you have 10% of the total capacity. You bring it online just after the difficulty increase. You mine 10% of 2016 = 201.6 blocks.Suppose you could have entered online sooner, at 80% of the previous round where you had 13% of the capacity. You mine 0.13*0.2*2016=52.4 blocks. It increases the difficulty by extra 2016/(2016-52.4)=2.7%. You mine next round 201.6/1.027=196.3 instead of 201.6. Net gain of 52.4-(201.6-196.3)=47.1 blocks. |
|
|
|
This is only on MtGox. If other markets follow, than the price drop is for real.
Bitcoin Central followed and other markets are negligible. I think anybody who wants a long-term success of Bitcoin should welcome price drops. There was nothing healthy in the rush to parity. The Bitcoin economy should grow by increase in the number of transaction and the value of items and services exchanged and not by price speculation. |
|
|
|
Well if I was going to bring a rack-mounted GPU cluster, or similarly expensive GPU rental, etc, on-line I would schedule delivery, installation timing to have it coming on-stream immediately after a difficulty increase. You get a temporary leg up over the existing competition until the next difficulty increase.
It does absolutely not make sense timing bringing up capacity online. The most optimal strategy is to mine as soon as possible. A mined block is worth more than the loss resulting from difficulty increase of one's mining in the next round. |
|
|
|
|
Anybody succeeded porting it to Linux? I have no success so far.
|
|
|
|
The high returns last year are a bit misleading, because most people were mining with CPUs and it was not possible to achieve anything near 100 MHash/s.
Well, yes but the unit is for just today's mining capabilities. One can divide by 100 and get a daily income per 1Mh/s which was achievable back then. |
|
|
|
Still, there has really been a sudden increase:
It's not unprecedented. There were >40% jumps last year frequently. Of course it was easier back then where a single 5970 meant a few percent of the global hashspeed but today as long as everybody increases its mining capacity by 40%, we have such a jump. Or everybody keeps the same but there are 40% more miners. Or a little of both. Mining was extremely profitable recently, the $/hash was at the November level where the jumps were large. http://bitcoin.atspace.com/income.pnghttp://bitcoin.atspace.com/income.htmlThere will still be significant jumps in difficulty as long as mining is so profitable. A crash in BTC/$ market can only stop it short term. If the BTC price stays the same, we will probably see a few 30%-ish increases in difficulty and it will gradually slow to 10-20% increases like in January. edit: proper page linked |
|
|
|
b) you get sent 1.0 btc and the system keeps the 0.00057054 in your pool.
The correct answer is b). Small detail. The pool checks the threshold every full hour. So if you cross the threshold at 10:05, you have to wait until 11:00 for the payment. |
|
|
|
|
Your glibc is not compatible with glibc used for building the binary,
It's best if you compile bitcoin from the source. It is rather straightforward. Follow the instructions from build-unix.txt.
|
|
|
|
I know, the script is not a problem - but where in the code do I add it (and how  )? At the top of BitcoinMiner.py add Near def blockFound(self, hash, accepted):
add def sendmail(self):
os.system("./your_mailing_script")
In def blockFound(self, hash, accepted):
add The script will run if the block is either accepted or invalid/stale but the latter is also important to know. You can add hash and or date to the arguments. Remember than in Python indentation matters. |
|
|
|
I have argued that difficulty should be proportional to price. Difficulty will rise until mining becomes unprofitable. Since the price recently tripled, difficulty should do the same.
Difficulty should actually increase roughly 20-fold to make ATI 5xxx GPU mining unprofitable. We have plenty of room for difficulty increases at current price levels. |
|
|
|
I am actually installing using the in-built graphics card and am going to try and install the 5970 later. Do you think this will work?
Hopefully. But this is rather strange because Ubuntu does not use the Catalyst drivers during installation and this is a problem in open source drivers (or hardware). Maybe after installing the complete system and the Catalyst drivers everything will be OK but who knows. Anyway, you will need at least access to console to install the drivers. |
|
|
|
|
I had a similar problem with my dual 5970 installation (but in contrast to your problem, it worked fine with a single card). It turned out to be ATI Catalyst bug and upgrading to 10.12 solved the problems.
Could you try to log into console while booting? Ctrl-ALT-F1 should give a login screen. You may also try installing openssh-server and login remotely (actually I had to do this way because console did not work) but it maybe hard when there is no full system.
You may indeed try installing the system with one card and try installing the drivers later. There is also possibility of a motherboard-card conflict. Does it work with Windows?
|
|
|
|
Performance: 2.3 MHash/s per core on 2.3 GHz CPU [1000 CPU cycles per hash]
What architecture? It will be excellent for Intel Core, Core2 or Core i3-7 and old Athlons K8 but not impressive for Athlons K10. |
|
|
|
"Anti cheating" is totally a straw-man's argument. How can the Hall of Fame can be used to cheat the pool?
If I'm wrong then please explain how can the Hall of Fame be used by me or anyone else to cheat the pool?
Cheating requires knowing when the current round started. Somebody can monitor Hall of Fame and notice incrementation of the scores which with 60% probability suggests a new round. But why not delay the Hall of Fame by 2 hours? |
|
|
|
|
Show Posts
