|
Yep, have been hitting the open file limit. My guess is that either someone is messing with me or a big new user is trying the pool with their several hundred connections.
I've increased max conns and added some tracking to see who is doing this. Hopefully it is legit (or at least a well operated bot net).
|
|
|
|
|
Yeah, someone was going awry. If it happens again I'll start getting drastic on it.
|
|
|
|
|
We just got a block and I threw in the rest of my personal savings so it should be good for a while.
I'll release the code in a little bit. It isn't anything magical.
|
|
|
|
@FD,
Sorry to see the pool stats as they are - cross my fingers that a good luck streak is hit.
Is there a donation address for the pool?
I certainly wouldn't seek donations, I am intending this as a for-profit operation. However, I wouldn't turn down donations. If you are so inclined, you can send too the main pool pot: 1HHTTPaz86gcxqntnjZMHbaoF4EvyYZCka If the luck doesn't improve, here is what will happen: Whenever there are funds, the pool will send what it can proportionally to what is owed. This will keep on until everyone is paid, including whoever (reasonably) elects to stop mining on the pool. Regardless of how long that takes, at the very least my two singles will be on the pool and my two SC singles when they come so some blocks will come in and payments will go out. I certainly understand anyone who decides to switch pools if that happens. I know most people are not looking for variance. Really I started this pool to raise awareness of lowering mining overhead by increasing difficulty and that goal is accomplished. |
|
|
|
Are you really 60 BTC in the hole? This has me worried. How can you keep going with those kind of losses? Income Paid Net
400.00000000 460.36536787 -60.36536787 I am absolutely that far in the hole. I have some sort of organic poptart that tastes like sadness. I nibble it as I ponder what I have done to get myself where I am. I have regrets but not that many. |
|
|
|
Can you develop an alternative game where the I can win what I actually rolled? for example, I rolled a 18, but my bet was on lessthan 64000, so I missed out on a potentially big payout. In this alternative game, if I roll a 16, then I get paid the 1998.853x multiplier or whatever multiplier that would be mathematically correct. I'd like to play this style.
If they paid 64000x for every zero, 31981.573x for every 1, etc. using the current payouts, the expected return per 1 BTC bet would be 9.3 BTC. So to make a game with a small positive (1.9%) expectation for the house, but with the same proportions of the payouts, we need to scale the current multipliers back by 9.3 / 0.981. I left the 'losing' return at 0.005, and slightly adjusted the 3rd decimal place of the payouts to make it work. Then we get: lessthan 1 6750.942x
lessthan 2 3373.527x
lessthan 4 1686.764x
lessthan 8 843.382x
lessthan 16 421.691x
lessthan 32 210.846x
lessthan 64 105.423x
lessthan 128 52.712x
lessthan 256 26.356x
lessthan 512 13.178x
lessthan 1000 6.747x
lessthan 1500 4.498x
lessthan 2000 3.374x
lessthan 3000 2.249x
lessthan 4000 1.687x
lessthan 6000 1.125x
lessthan 8000 0.844x
lessthan 12000 0.563x
lessthan 16000 0.422x
lessthan 24000 0.282x
lessthan 32000 0.211x
lessthan 32768 0.206x
lessthan 48000 0.141x
lessthan 52000 0.130x
lessthan 56000 0.121x
lessthan 60000 0.113x
lessthan 64000 0.106x
64000 or more 0.005x
Which gives pretty much the correct house edge: >>> (
1 * 6750.942 +
1 * 3373.527 +
2 * 1686.764 +
4 * 843.382 +
8 * 421.691 +
16 * 210.846 +
32 * 105.423 +
64 * 52.712 +
128 * 26.356 +
256 * 13.178 +
488 * 6.747 +
500 * 4.498 +
500 * 3.374 +
1000 * 2.249 +
1000 * 1.687 +
2000 * 1.125 +
2000 * 0.844 +
4000 * 0.563 +
4000 * 0.422 +
8000 * 0.282 +
8000 * 0.211 +
768 * 0.206 +
15232 * 0.141 +
4000 * 0.130 +
4000 * 0.121 +
4000 * 0.113 +
4000 * 0.106 +
1536 * 0.005) / 65536
0.9810327911376953
Would people be willing to play a game where you need to roll less than 6000 to 'win'? It means that less than one ticket in ten is a winning ticket. That sounds like a really cool game and I don't see a crypto problem or any large barriers to implementation. |
|
|
|
What does it look like for time when you just do the getwork from the command line?
fireduck, I've just made three tests summary: 20sec,10sec,20sec spiccioli Ok, wow. That is certainly a problem. Those should be taking less than a second. I haven't seen any take nearly that long. Can you test some other things around the net to see where that latency is coming from and do some pings and traceroutes around? |
|
|
|
What does it look like for time when you just do the getwork from the command line? : time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"c64f8ea2f7221136c976492613fe1822122847ce5e92793c13dfcb1b1b8598a6","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"000000023e0344e6e5855b24ffdbee62e4c57bcfb52adc64a5a7779b000004fd00000000098c59bc923d77e04002fd2374f6bf6a2c63d19fe179f1d4512cbe0db38ba923506368101a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m0.057s
user 0m0.001s
sys 0m0.008s
|
|
|
|
I'm using difficulty 32.
I'll try to use 256 for a while, but it seems to me that the problem is in requesting more work, not in submitting less.
Cheers,
spiccioli
It could also be the clock on your system. If you clock is off your mining software might think it is unable to change the time on the work unit to scan for more good nonces. If it can't do that, it will end up having to request a lot of work from the server since it will only be able to do 2^32 hashes on each work unit. |
|
|
|
hi fireduck,
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
What difficulty are you using? If you are seeing that, my guess is that you need to increase that number. At 7GH/s 128 or 256 would probably be good. |
|
|
|
Is there any way to make the usage graph less "spikey"? It shows peaks that go well above (more than 50% above) my hash rate. I realize there is an extremely smoothed version at the bottom of the graph, but can the main part of the graph be smoothed at all? Maybe take a measurement over a longer period of time, like every average of 10 minutes instead of 1 minute for example?
Each datapoint is the average for an hour. I've just experimented with some larger time periods and it loses a lot of data. I could make it configurable so you can look at whatever data point size you like. |
|
|
|
Now it does. Isn't blockchain.info's fault, the transaction just had not found accommodation in a block yet. All is well.
I think it was my fault. One of my local bitcoinds was acting like a princess and not relaying anything as far as I could tell so the transaction wasn't getting broadcast. |
|
|
|
What do you think?
I would allow tor users. Why not? I imagine it will all be botnets, but that is fine. If my computer has some stuff on it, I'd prefer it get hot mining as I might notice that and correct the problem. Otherwise, I'll have no clue my box is rooted all the hell. I am not the internet police. If peoples' computers getting hot and higher power bills are what it takes for there to be some incentive to unfuck OS security, fine by me. |
|
|
|
I would like to include HHTT - I love the fact its selling point is variable diff and it's hashrate jumped a lot recently.
Early on I just included all pools. I can't do that now. Every Sunday someone changes a webpage and I have to rewrite scripts to cope. Last weekend I discovered DeepBit had changed the stats table to the 13th position on the page, and Eclipse added a field to their json which I also had to account for. This is after I finally figured out the problem in each case.
So now I just ask for a csv blockhistory. If extra columns need to be added to for some reason my scripts can simply ignore the new data. If HHTT would like to be included, then I'd need the following columns as csv:
"blockheight" | "timestamp" | "shares" | "roundseconds" | "difficulty" | "orphaned" | "blockhash"
doublec did this for me and I know as long as the csv is available I'll never have to waste time on a Sunday trying to fix data for Bitparking!
I'm working on it. Any particular format for the timestamp? For the difficulty, do you want the network difficulty when it was solved or the difficulty that block would meet? |
|
|
|
|
I would like to explain a recent bug that has been plaguing our system and how it was corrected.
In our system we have a database of all transactions that relate to Satoshidice. We also track their status (pending, confirmed, unknown). We get a handful of transactions that were broadcast but never end up confirming. After 24 to 48 hours we delete them from our system and move on. There was an issue where the status of the transactions was not being recorded correctly. So we would occasionally delete a transaction thinking it was hopeless when it actually confirmed some time ago. Then the outputs spend for that transaction would be marked available and used to pay other transactions. The more I ran the recovery process to clean things up, the more of these ended up getting created.
Now I have a separate safety check that checks an external repository of confirmed transactions before deleting anything. This has been running for about 3 days and seems to work very well.
The other thing that happened that led to a large amount of unconfirming transactions was around Sept 8th we ran out of confirmed funds. We try to always pay winners with confirmed outputs so there is no problem getting them confirmed and they are not dependent on anyone else's transactions. Well, we ran out of confirmed and started paying with pending funds. This of course didn't go well and a bunch of payment transactions had to be deleted and reprocessed.
We of course have alarms on confirmed funds and were notified as it was going down but Erik was traveling and I don't have access to the reserve funds so there was not much I could do, other than later run the recovery and cleanup tasks to get everyone paid.
|
|
|
|
Why was I getting nothing for many valid shares?  This is happening again. September 14th 05:17 Yeah, that is what happens when a task I have isn't able to update the database with those values. The shares are still recorded and are given amounts correctly when it does run. I'll add an alarm on that so I know about it earlier. |
|
|
|
Pool had a couple of minutes downtime as I upgraded some software. The main improvement is adding the ability for miners to select their own difficulty level to mine at. It defaults to a difficulty of 1 but if you set your miners password to "d=8" you will mine at difficulty level 8. You can change "8" to any number. All PPS rewards will be multiplied by that value. It should be a non-decimal number. This will result in less submissions to the pool reducing bandwidth and improving performance.
Cool, I think this is an important change for bitcoin mining. Also, my site is prettier. |
|
|
|
|
I just did a database upgrade. Now this pool has its own RDS instance rather than using the shared one on my web server.
The pool was down for a few minutes during the switch over.
|
|
|
|
|
Stales are now being paid for. All past stales are also being paid (although at the current network difficulty).
|
|
|
|
Interesting.. I did not know that there was already a mechanism in place for increased difficulty shares. Do all the common miners already support this?
There is a mechanism for it, a getwork request returns a target difficulty and all the software I've tested accepts it and does the right thing. My mining pool is the only one I know of that allows miners to select their difficulty (but I don't expect this to be true for long, others will almost certainly do it). http://hhtt.1209k.com/ |
|
|
|
|
Show Posts
