Very good question.
Maybe the idea was not to scare people with exp(-t) curves? But, yes discontinuities are quite worrisome.
It could have been more frequent smaller reductions if it had to be stepwise though. I'm excited to see what happens and I don't think it'll be a problem. But it seems unnecessarily eventlike. I think it'll be price up in anticipation and about 2 hard difficulty reductions after the drop then leveling off at about 75% of old difficulty and resuming a rise from there. Yes, but what if it is just what bitcoin needs to create a stir, garner publicity and demonstrate resilience; an event that it survives, at the same time exactly half of the bitcoins will have been found?
|
|
|
Kind of nice mathematically how it is .... being a special case of Jakob Bernoulli's summation of infinite geometric series formula
a + ar + ar2 + ar3 + ... + ark + ... = a/(1-r)
where a = 10.5 million btc and r = 1/2
The first jump from 50 to 25 is going to be the most disruptive, relatively speaking.
Could see as it the final system test, survive that and you can survive anything.
(Gonna be one hell of party on 1/3/13 if its still rocking on up this growth curve.)
|
|
|
700 Mhash/s on 5970 at stock freq and voltage are not realistic. Fyi the card has 725 or 735 MHz per core, and this barely stables the mhash/s at 280 with BFI_INT. At 755 the card stables between 300 and 315 Mhash/s. Anyway most of miners use SDK 2.1 which is not so problem-free under Linux.
Underclock mem. to 300 and 5970 can do 312 Mhash/s per core on stock clock freq. (BFI_INT latest poclbm or phoenix 1.4).
|
|
|
global unique ID ... is this the puke symbol how much more facist do you want to make the money than it already is ?
|
|
|
I'm sure all the F@H CPU/GPU combined has a way higher TFLOP than Bitcoin...
I was going to say, they just hit 7 PFLOPS in march. How can we be at 15 PFLOPS?! Individual incentive, happily the bitcoin network has some pretty significant communal benefits in the longer term also ...
|
|
|
Wow, the website is that good eh?
|
|
|
Couldn't that "short block variance" be mitigated by calculating rewards/shares for multiple blocks instead of dividing them one by one? With a straight, proportional payout system it would simply mean that shares for blocks that are found in less than XX minutes are transferred to the next block.
Maybe, but you'd have to get a "big" pool operator to implement that ... it becomes quite a messy calculation of who's working harder on which particular block, who was luckier on which block, rolling averages over multiple blocks, time-depreciating share values to stop "pool hopping" attack, etc. Bottom line is, right now the little guys are losing out when a pool gets too big, their variance starts going up again.
|
|
|
I think you may need a step after 12. 12a. echo export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.1-lnx64 >> .bashrc As per the ATI documentation. The miner will run fine without it but later upgrades, builds, etc may need this variable. Also, I have a recollection that "python-jsonrpc" is no longer necessary to be installed ... but icbw.
|
|
|
There is an incentive to not mine with deepbit.net (or any other pool) as it gets too big, particularly for the smaller miners.
The pool is there to smooth out the variance. But if the pool is finding blocks too quickly then a smaller, proportional miner may not get that many shares of each short block found and variance starts to return again, and more luck is involved. If you go pay-per-share this is smoothed out but at the cost of 10% fee with deepbit.net.
The smaller miners are better off with a pool that is finding blocks over a good period of time ... 1-2 hours, so that their share of the pool is well-represented and has had time to average out.
I'm sure if someone is interested, there is some mathematics to be done here that will give you an optimum size of a pool to associate with (as percentage of total network) dependent upon on the miner's hash power (as percentage of the pool), in order to minimise variance .... if that is what you are after.
Robust payments, low fees, info API's, and other bells 'n whistles maybe what you are looking for in a pool also.
|
|
|
69 Ghash/sec .... and climbing. ... any warning lights flashing, rivets or screws popping out yet dbitcoin??
|
|
|
Yes. Technically any amount of money earned more than about $500 the IRS "requires" you to report it. Define "money".
|
|
|
After watching the bitcoin growth since early in the New Year I feel it is now time to put forward a project I have been evaluating since then. I am investigating putting together an operation to purchase/lease one of these cabinets from SGI. http://www.sgi.com/products/servers/prism_xl/From my evaluations so far, it is the best technically 'GPU cluster in a cabinet solution' currently on the market suited to mining. They can supply an option to run 5970's. http://www.sgi.com/products/servers/prism_xl/specs.htmlThe basic strategy at this point is to set-up the machine to mine. It can alternatively perform any other HPC tasks that customers may feel like submitting to the machine based on market rates for the machine's time and bitcoin output. I'm a hardware/linux/real-time-control/networking/system engineer but have a wide experience base and a jack-of-all-trades skill set. I have access to experienced HPC programmers and sys. admins who can work on contract. I have some funds (and much time) to invest but not enough to carry this whole project on my own and am therefore looking for a solid backer and/or business partner(s). Please PM me for further details/discussion and expressions of interest. Note: I will not be answering questions related to this venture on the public forum. PM serious enquiries only please.
|
|
|
After watching the bitcoin growth since early in the New Year I feel it is now time to put forward a project I have been evaluating since then. I am investigating putting together an operation to purchase/lease one of these cabinets from SGI. http://www.sgi.com/products/servers/prism_xl/From my evaluations so far, it is the best technically 'GPU cluster in a cabinet solution' currently on the market suited to mining. They can supply an option to run 5970's. http://www.sgi.com/products/servers/prism_xl/specs.htmlThe basic strategy at this point is to set-up the machine to mine. It can alternatively perform any other HPC tasks that customers may feel like submitting to the machine based on market rates for the machine's time and bitcoin output. I'm a hardware/linux/real-time-control/networking/system engineer but have a wide experience base and a jack-of-all-trades skill set. I have access to experienced HPC programmers and sys. admins who can work on contract. I have some funds (and much time) to invest but not enough to carry this whole project on my own and am therefore looking for a solid backer and/or business partner(s). Please PM me for further details/discussion and expressions of interest. Note: I will not be answering questions related to this venture on the public forum. PM serious enquiries only please.
|
|
|
Wahoo ... I think this is our first on display rack stack ... although some more commercial secretive maybe into that already (vlad, ArtForz, etc).
The racks/cabinets is going to be the way to go for bigger set-ups .... I think a few more months and more big iron techniques and engineers will start to take over from the gamers.
We could be looking at the end of the IBM dominance for big finance machines if this model for massively distributed/networked capacity takes off.
|
|
|
Been wondering about legal status of bitcoin ownership and it is very, very nebulous. As you'll notice in the disclaimer in my signature I admit to possessing keys but not to bitcoins themselves (this was for the purposes of 'disclosure' to jokingly avoid accusations of conflict of interest).
The coins are held in the database that is distributed in the network, so I, myself, do not actually have possession of the bitcoins, the network does. I hold the keys to access certain coins but can only do so with the collaboration of the network. The closest thing in current law might be a custody arrangement but since the network is not a legal entity, like a bank, then it is not clear who actually has custody of the coins, or if they even exist as assets at all, under current legal definitions. Are the coins really there? The only way of verifying that is to move them into another asset class, up until that point they do not really exist legally speaking, particularly not until the bitcoin network is recognised as a legal entity existing in its own right, like a bank.
So I'm not convinced that legally I actually own anything except the keys. Maybe the keys could be classed as virtual good, but not the bitcoins themselves since they do not really exist as an asset in any legal definition. If I use those keys to make a transfer that results in US, or other state monies or assets that the state recognises, then maybe I'm liable for tax on any profits of bitcoin activity. Until the keys are used for an exchange into 'real' assets (bits in US$ bank account) I'm struggling to see where the liability comes from, legally speaking.
|
|
|
Moa,
Its not a good idea to use the -9 argument here. This shuts down the processes without allowing them to do shutdown gracefully. just use kill <processid> or pkill <processname> and this will give the process a chance to shutdown correctly.
Yeah, you are right ... i've got into bad habit of always kill -9 since I mostly use it on hung/runaway processes ... for a scheduled cron shutdown drop the -9 ... just kill or pkill should be good.
|
|
|
Parity ... it's gone baby gone.
.... we are more likely to see 10 before we see 1 again, my latest pick is for the next strong rally phase to take us in to the low 7s area ... unsure what will trigger that rally and how long it maybe away though, weeks or even months probably.
|
|
|
yeah, like nobody is aware of the fucking gargantuan taxes the banksters are shafting us with every year .... !
|
|
|
Yes, use your knowldege wisely ... don't go over to the dark side.
|
|
|
|