BurningToad:
We appreciate your efforts in running this pool. It is one of the most stable and reliable pools around. We know you don't get paid, and in fact, do not make enough in donations to even cover costs. We do realize the many, many hours of work you put into this.
Do what you need to do to keep this pool at it's current high quality, and we will support you.
Topic: [0 GH/s 0% fee SMPPS] ArsBitcoin mining pool! - page 36. (Read 123721 times)
Hello,
The pool has grown beyond its ability to scale well and provide a high level of stability and service. See hashrate graph here:
http://stats.nuradu.com/
Therefore, I am temporarily closing registrations until I can provide a solid level of service to current members. I am also thinking about the possibility of a mandatory fee in the future of 0.5% to 1%, but I am undecided. This fee would help cover my costs and give me the ability to add additional servers if needed to help scale and support more users. If I implement a fee, I would give at least 24 hour notice and email all current members.
Now that registrations are closed, my top priority is to scale the current code/server to be able to support a higher load. Once again, though, there is still currently no mandatory fee.
Thanks for your understanding!
The pool has grown beyond its ability to scale well and provide a high level of stability and service. See hashrate graph here:
http://stats.nuradu.com/
Therefore, I am temporarily closing registrations until I can provide a solid level of service to current members. I am also thinking about the possibility of a mandatory fee in the future of 0.5% to 1%, but I am undecided. This fee would help cover my costs and give me the ability to add additional servers if needed to help scale and support more users. If I implement a fee, I would give at least 24 hour notice and email all current members.
Now that registrations are closed, my top priority is to scale the current code/server to be able to support a higher load. Once again, though, there is still currently no mandatory fee.
Thanks for your understanding!
Is there an optimum surplus level for the BTC pool?
I can't verify the math, but I asked Meni Rosenfeld to do some numbers for me here: http://forum.bitcoin.org/index.php?topic=27870.msg376769#msg376769
Using some assumptions that won't hold steady (like pool hash rate), according to Meni, the probability that the SMPPS buffer will be negative exactly a year from now is about 33%. The probability that the SMPPS buffer would be negative at any point during the next year is 66%. So we haven't reached an "extremely safe" buffer amount by any means.
Is there an optimum surplus level for the BTC pool?
Hi, thousand thanks for your pool. Finally I can mine anytime I want as long and short as I want without worrying about "missing a lucky block". It's perfect for people like me not mining 24/7.
I get a steady stream of BTC directly related to my power usage and I don't have to worry about the pool's hashing speed.
Thanks!
I get a steady stream of BTC directly related to my power usage and I don't have to worry about the pool's hashing speed.
Thanks!
Sorry, but storing monetary values in floats is just... something I really don't like. At all.
Having more than 8 decimals ready is nice, but using floats for that is just not the style of coding I support at all. Bitcoins are atomic units.
Having more than 8 decimals ready is nice, but using floats for that is just not the style of coding I support at all. Bitcoins are atomic units.
I am sure BurningToad would be happy to review any coding you submit to him for possible inclusion into his pool. I don't doubt that he could use some help, what with running this 0% fee pool that has sextupled in size in three weeks all by his lonesome.
Frankly, I don't think you've got much to bitch about...
Personally I love that pool. Stales are too high, though. Last days on BTC I got less than .2% stales, here I am at 0.57%. Stales seem to be a little too often. Server not powerfull enough?
The remaining sources of occasional connection issues are:
1) Sometimes the 5 min stats calcs can cause issues. This is usually when there hasn't been a new block on the bitcoin network in a while (30 min+) which is a trigger for some behind the scenes work. I can improve this in the future.
1) Sometimes the 5 min stats calcs can cause issues. This is usually when there hasn't been a new block on the bitcoin network in a while (30 min+) which is a trigger for some behind the scenes work. I can improve this in the future.
I improved this cause of RPC errors as well.
I will tell you why it makes sense to store it as a double. Currently, each PPS share is worth 0.000031989190 BTC. If you round that to a satoshi, then you only get 0.00003198 BTC.
You could save it in 1/1000000 satoshi (feel free to add zeroes), which still is an integer and therefore allows precise addition and multiplication. Floats and doubles simply tend to give off-by-small-amounts results when calculating, and those add up with time. Floating point arithmetic shouldn't be used with financial data. http://speleotrove.com/decimal/
However, numbers with 1/1000000-satoshi-units might be too large for either PHP (without extensions for arbitrary size integers) or the database system, so double is probably a good compromise. It seems to work well.
Sad to hear that, added to the post above as well!
Sad to hear what? That I don't display a gajillion decimal points on the site? Or, doubles aren't precise enough for you either?
This is personal preference of a purist nature and anyone unhappy with double floats is welcome to find another pool. This is along the lines of the 80/20 rule wherein 80%+ of the complaints are raised by 20% or less of the participants.
Other than the recent disconnects, Ars and Eligius are the most consistent pools for me. Thanks for putting in the effort.
I will tell you why it makes sense to store it as a double. Currently, each PPS share is worth 0.000031989190 BTC.
Actually, behind the scenes, each share is currently worth: 0.000031989190292329. Once again, the number is rounded for display on the site only.
The issue is various stats calulations and database work that can cause intermittent connection issues (especially on block confirms.) I think I may need to remove some of the per-round stats (like shares per round) and put in shares per day instead. This would be a quick fix until I can use some more efficient methods. However, I think this would be good to do so we are losing as few shares as possible to connection issues.
I have made a change to stop the hash rate drop at 120 confirmations. This should mean that there are less connection issues and everyone should be able to get more shares in.
The cost at the moment, is the per-round user share history at https://arsbitcoin.com/blocks.php. I will display some new stats soon for daily shares submitted and exact PPS number in a table. The PPS numbers are in that chart now, but I think a table would be nice too.
The remaining sources of occasional connection issues are:
1) Sometimes the 5 min stats calcs can cause issues. This is usually when there hasn't been a new block on the bitcoin network in a while (30 min+) which is a trigger for some behind the scenes work. I can improve this in the future.
2) Database backups can still cause issues. Someone already provided me a solution for this, but I have not had time to implement yet.
I will tell you why it makes sense to store it as a double. Currently, each PPS share is worth 0.000031989190 BTC. If you round that to a satoshi, then you only get 0.00003198 BTC. You lose .9190 satoshis for every share. If you look at ArsBitcoin's lifetime shares, you will see the number one person having 3,647,233 shares. If he lost .9190 satoshis for every share, he would have earned 0.03351797 BTC less. It's not much, but it's still something.
I personally think BurningToad should round down (not up!) and keep the change as fees. But I applaud him for trying to be as fair as possible.
I personally think BurningToad should round down (not up!) and keep the change as fees. But I applaud him for trying to be as fair as possible.
Then how do you deal with the fact that 1 share is unlikely to be an exact number of bitcoins, even if you use nano, or even pico-bitcoins?
At some point you must round up or down, and in that case someone loses and someone gains from it. Storing numbers to the limit of double precision and then round UP (as BT says), seems to be pretty fair to me. Especially as the limit of bitcoins is 8 decimals?
At some point you must round up or down, and in that case someone loses and someone gains from it. Storing numbers to the limit of double precision and then round UP (as BT says), seems to be pretty fair to me. Especially as the limit of bitcoins is 8 decimals?
Sorry, but storing monetary values in floats is just... something I really don't like. At all.
Having more than 8 decimals ready is nice, but using floats for that is just not the style of coding I support at all. Bitcoins are atomic units.
Having more than 8 decimals ready is nice, but using floats for that is just not the style of coding I support at all. Bitcoins are atomic units.
I'm assuming he means "glad to hear that".
The other thing that you could do is store everything as integers (ie multiply 1 bitcoin by 1e8), and always keep the single share value as an integer value too. Still gonna lose 1 unit either way in the rounding for the per share value.. but maybe it'd keep Sukrim happy?
The other thing that you could do is store everything as integers (ie multiply 1 bitcoin by 1e8), and always keep the single share value as an integer value too. Still gonna lose 1 unit either way in the rounding for the per share value.. but maybe it'd keep Sukrim happy?
Sad to hear that, added to the post above as well!
Sad to hear what? That I don't display a gajillion decimal points on the site? Or, doubles aren't precise enough for you either?
From the decimals displayed it seems you are using FLOATS to store Bitcoin values! 
I'm off here until this is either explained or fixed. (Never. Ever. Use. Floats!)
I'm off here until this is either explained or fixed. (Never. Ever. Use. Floats!)
The decimals I am displaying on the site have nothing to do with how they are stored on the back end. The site has things rounded to 8 decimal points for most things, 12 for the PPS share count, but underneath it is not rounded, and is stored as doubles.
From the decimals displayed it seems you are using FLOATS to store Bitcoin values!
I'm off here until this is either explained or fixed. (Never. Ever. Use. Floats!)
I'm off here until this is either explained or fixed. (Never. Ever. Use. Floats!)
The decimals I am displaying on the site have nothing to do with how they are stored on the back end. The site has things rounded to 8 decimal points for most things, 12 for the PPS share count, but underneath it is not rounded, and is stored as doubles.
Right now the pool actually overpays each time you get a payout as well, as it rounds your balance UP, for example, 1.021022222 will become 1.02102223 on payout, then your balance goes to zero.
Is the server at max load? I am showing some connection issues every so often.
Just curious...
Just curious...
The issue is various stats calulations and database work that can cause intermittent connection issues (especially on block confirms.) I think I may need to remove some of the per-round stats (like shares per round) and put in shares per day instead. This would be a quick fix until I can use some more efficient methods. However, I think this would be good to do so we are losing as few shares as possible to connection issues.
Jump to: