|
Other jurisdictions besides the US could profit mightily from running future bitcoin exchanges. Hong Kong, Singapore, London, Zurich, Moscow, Rarotonga, Cayman Is., who knows where a server can be set up?
I wonder what Wall St. would think of legal moves to cut them out of that action?
|
|
|
|
|
Or several big stealth buyers .... the forbes magazine guys who read it in bed in their smoking jackets at the hamptons spent the first 24 hours thinking "wtf is this, geek money!? huh?" ... the next few hours ringing brokers etc to see how they can get in on it ... and now show up ... that's the sharp or desperate ones ... the big rollers will be slower and more methodical like elephants but it will be unmistakeable if they show up ... 0.02 btc worth.
|
|
|
|
Now that difficulty is at 157,426, I'm wondering what you guys plan to do? Add more rigs  ? Who here plans to stop mining? my mining with my not-yet-week-old card will continue until it is no longer profitable. which at current power rates and bitcoin prices, would be about 1.3 million difficulty. BTC just went to $5 on Mt.Gox ... need to get out that damned calculator again ... anybody got a good spreadsheet? |
|
|
|
well, fuck my life... 5$? really? I basically lost 150$ right now ,because I sold a few hours too early? This is what I hate about BTC  Someone decides to buy alot and voila, his BTC is already worth over 50% more Only if you continue to measure things in depreciating fiat currencies .... measured in BTC he has no more or less .... see? Lesson one, don't sell your BTC unless you are starving, cold or need sex. |
|
|
|
|
Yep, cleaned out all the sells all the way up to $5 ... gonna be a $5 plus weekend, .. probably $7.50 is next place for a pause cause there ain't much on the sell side at the moment.
|
|
|
|
Thanx for confirming that for me ... i suspected it would be the case since i have found not max-loading up the default display adapter with mining reduces number of kernel hangs markedly ... now need to get hold of cheap mobo with onboard graphics chip and 4 or more PCIe slots ....
Make sure the onboard graphics is ATI and not nvidia. The ATI and nvidia drivers do not play well together. Already been down that path myself. Thnx, good point ... amd all the way. |
|
|
|
They just felt like they got small pee-pees because they found out bitcoin miners can run their machines harder than gamers ....  Get hard, get bitcoin mining .... get some monies. |
|
|
|
Looks like this puppy is pretty much dialed in now.
The median forecast Difficulty for block 122976 was 159421, the actual difficulty is 157426... A variance of only 1.3%...
Now let's see how well the model works on the next re-target.
So what's the difficulty increases for the next 6-12 months look like on your model? |
|
|
|
|
Yes. If block reward halves and there are enough people who 'need' to make transactions that cannot wait a few months, then it should spur an increase in transaction fees .... or those 2016 blocks after 1/3/13 could take a looooong time, no free transactions during that period I'd think.
|
|
|
|
|
Maybe a small business partner or other worker to watch over pool when you are off-line? Meatspace watchdog.
bitcoind is open source so bug fixes are welcomed i'm sure.
|
|
|
|
export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.1-lnx64 and export LD_LIBRARY_PATH=/opt/ati-stream-sdk-v2.1-lnx64/lib/x86_64/:$LD_LIBRARY_PATH set these yet? |
|
|
|
I ended up activating my onboard gpu and using that to load kde. With the onboard being used as the default device I have no problem using -f 0 on the 5870s also the overclocks are more steady the only thing i need to worry about is the temp. When i was using one of the cards as the display card one or both would crash after a few hours due to the overclock. This may not be advisable to most but my hash rate when up about 10mhash percard with the higher oc and f0 flag
Thanx for confirming that for me ... i suspected it would be the case since i have found not max-loading up the default display adapter with mining reduces number of kernel hangs markedly ... now need to get hold of cheap mobo with onboard graphics chip and 4 or more PCIe slots .... |
|
|
|
Here is a way to get around paypal's rules about selling currency. You setup your website so the user can have a balance in BTC and USD (or whatever currency you like). You use paypal to add money, or cash out from your sites USD balance. Another way is to sell "tokens" or whatever you want to call the balance on your site. Your site will then do conversion between BTC and USD using the balance in his account. The difference here is that you are not selling currency (BTC) with paypal, you are selling tokens for your site. You could also do it more practical, like sell email addresses ( customer@yourdomain.com) for $50. Then allow customer to sell the email address back to you for bitcoins. It doesn't have to be emails, you could do this by selling anything that you can create one time and does not cost anything further to distribute, like software license keys etc... Again here your not directly exchanging BTC for paypal. Precisely right. Selling crypto-keys associated-with/linked-to/backed-by merchant held accounts is perfectly acceptable. Open Transactions already has all the machinery in place for merchants, exchangers to do all this, essentially issue their own keys/token/licences/currency (call it whatever you like at this point) Merchant Credits ... OT can do all this if someone wanted to just use the back-end library and API, then put a web interface on top of it. |
|
|
|
Giving it a try...
What's with the income from transactions? (7 Bitcents currently from the 2 blocks so far)
Maybe list it as well in the payout history stats, even if you keep 100% of it.
Transaction fees are currently kept by the pool, which is the only "reliable" income generated by the pool. To my knowledge no pool splits transaction fees among the miners at this time (correct me if I'm wrong!). Once transaction fees are more common, and the BTC generated by blocks shrinks, they will get included with the total block split among the pool. I'm working on setting up the conditions for when that switch will take place. This is great. I don't know of any other pool that is being transparent about transaction fees, yet. It is not important right now but it is good to know the operator recognises this up front what may eventuate, it will avoid future crap fights, bad feelings. One more question will your server allow ping testing ... $ ping btcguild.com
PING btcguild.com (74.95.106.214) 56(84) bytes of data.
^C
--- btcguild.com ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6646ms
it doesn't seem to right now and I like to know how 'far' away from the pool I am .... in case comms needs to be considered for trouble shooting. |
|
|
|
|
No it's stability issue. Since Xorg is always querying the default display adapter GPU, the system will hang more often if you load up with mining the or OC too much the default GPU core. Basically, there will always be one core that is not a dedicated compute node, the default display adapter, since Xorg is always sticking its nose in and talking with that core.
Maybe a simple hacky hardware work around it is to get a cheap lightweight graphics card that can run as the default display (or better still a mobo with an on-board GPU) and then Xorg will leave alone the compute GPUs and you can load them right-up and OC to the max. It doesn't matter if you run as headless since as long as Xorg is running (which you need it to be to load the drivers) then it will be talking unnecessarily with that default display adapter.
There was some discussion on AMDs OpenCL forum for a way to set the default display to none or some such in xorg.conf but I never had any success with it ...
|
|
|
|
This rig and 2 more are under Windows so it's not practically wise to lower the memory so much because the fuckin "good" written driver crashes often.
Oh, on linux, SDK 2.1, it is rock solid 725/300 312 mhash/s ... sucks to windows eh? |
|
|
|
|
Okay, write it up (sounds like you've done it mostly anyway) and I'll take a look ... I'm interested how that works, if nothing else. Doesn't have to be flash, just the meat.
And your basic contention is that smaller miners are better off in bigger pools?
(This would be a big issue if the network is driven towards everybody mining for the same pool.)
|
|
|
|
Yes, a slow miner will see some "None"'s for short blocks, but sometimes he will hit such block too and it will be balanced out. But can he ever make up for the 0.5 or 0.75 of a share, i.e. the partial share that he should have got for the ultra-short round? Maybe it will be balanced out, eventually. The bigger question is how long will it take to make back the losses on a bad run? In other words, what is the ultra-short block variance for a small miner? Remember the primary idea of the pool is to reduce the variance for a smaller miner |
|
|
|
Great proposal, I wish many would be so elaborate  While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees. Not entirely correct. At some point, block reward will drop below 1e-9 btc ... i.e. below current resolution of the currency. At around k = 36 , in the formula above, i.e. in 144 years. |
|
|
|
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.
That's false. You'll have (proportionally) more variance per block but this is more than offset by the reduced variance in the number of blocks per time unit. I think that under some simplifying assumptions, the best way to reduce variance is to put all your mining in the largest pool, even if it is as high as 100% of the network. I think you'll find you are false. You've discounted the granularity involved that the difficulty 1 share system of scoring is placing on the problem. The ultra short rounds that the big pools get more frequently are essential for reducing the variance but a small miner can easily have a big fat "NONE" sitting in the shares column from one of these rounds. Because they could not find a difficulty 1 share in the same time it took the pool to find the block, they have no way to participate in the pool's mechanism for reducing variance for these ultra short rounds. It is the ultra-short rounds that have a large effect in bringing the variance back in the miners favour. Otherwise they are only toiling away on the longer blocks and not sharing in the ultra-short ones where they can 'make up' lots of lost time. |
|
|
|
|
Show Posts
