Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too - page 323. (Read 1601412 times)
February 27, 2011, 12:23:58 AM
Same speeds as on Slush's server, but am getting no stale's or invalids so far. So I'll be switching over for the time being as the stales/invalids were costing me as much as 5-10 percent. I think it may be the load on Slush's server, so hopefully yours will not have the same problem as it gets popular. I'll leave 2 5970's on your server and the other 2 on Slush's and compare after awhile. But, so far, excellent. I'd like to see even more competition to ease up the load on the various pools. I see this is in Beta. Hopefully you will not have much downtime. If you're down for an hour in a day, for example, that would cost well over the commission.
February 26, 2011, 11:52:01 PM
EDIT: Still, it would be nice if the right data was placed there, so I'd at least know which real block I am contributing to!
Do you clearly understand what a "share" is and why you are working with difficulty-1 task ?Just wanted to be sure.
I think so.
Or maybe I haven't understood something correctly again. 
February 26, 2011, 11:41:06 PM
After using the Pay-Per-Share for a few hours it seems to be working just pukka, apart from a slightly odd behaviour in the Account Balance (http://deepbit.net/acc.php)
It appears to track each new share perfectly in the balance sometimes, then will 'rewind' to an earlier value. Possibly in conjunction with an hourly balance update?
Thanks for your bug report. Just fixed that for displaying pay-per-share rewards. It appears to track each new share perfectly in the balance sometimes, then will 'rewind' to an earlier value. Possibly in conjunction with an hourly balance update?
February 26, 2011, 11:37:41 PM
EDIT: Still, it would be nice if the right data was placed there, so I'd at least know which real block I am contributing to!
Do you clearly understand what a "share" is and why you are working with difficulty-1 task ?Just wanted to be sure.
February 26, 2011, 11:36:34 PM
Are CPU miners not supported? It's okay if not. I just don't want to continue messing with this trying to make it work.
In the first post, the only one claimed not to work is the SSE2 miner. I got it to work with Puddinpop's RPC CPU miner, for instance
February 26, 2011, 11:35:11 PM
Are CPU miners not supported? It's okay if not. I just don't want to continue messing with this trying to make it work.
Just tested jgarzik's CPU miner and it worked fine for me.Try to use -P key and see, what it's trying to parse. Then copy it and send to me by private message, i'll try to resolve.
BTW it's deepbit.net, not www.deepbit.net. But works anyway.
February 26, 2011, 11:28:44 PM
Are CPU miners not supported? It's okay if not. I just don't want to continue messing with this trying to make it work.
February 26, 2011, 11:27:33 PM
After using the Pay-Per-Share for a few hours it seems to be working just pukka, apart from a slightly odd behaviour in the Account Balance (http://deepbit.net/acc.php)
It appears to track each new share perfectly in the balance sometimes, then will 'rewind' to an earlier value. Possibly in conjunction with an hourly balance update?
It appears to track each new share perfectly in the balance sometimes, then will 'rewind' to an earlier value. Possibly in conjunction with an hourly balance update?
February 26, 2011, 11:25:56 PM
Have you tried to look at other pool's work or your local bitcoin's one ?
3 blocks already found and they are surely not from testnet
3 blocks already found and they are surely not from testnet
I'm just quoting what the server at deepbit.net is returning in response to my "getwork" JSON requests.
I feel happy right now, as I just found my first "share", but I still don't understand why there are so few zeros in prev_block, since we are supposedly trying to generate real blocks.
EDIT: Maybe that part (first 64-byte chunk) of the "data" field is not filled correctly? I think it's not used by the SHA256 algorithm on the client, being already hashed by the server, with the result placed in "midstate", so that the client needs to perform only two rounds of SHA256.
EDIT: Still, it would be nice if the right data was placed there, so I'd at least know which real block I am contributing to!
February 26, 2011, 11:02:57 PM
I keep seeing this hash in the "prev_block" field in the data of the work that I get from deepbit.net :
Have you tried to look at other pool's work or your local bitcoin's one ?Quote
b84401536a5ec2fca283157d1ba9b80c0259a63954659d20000113dd00000000
3 blocks already found and they are surely not from testnet :)
February 26, 2011, 10:31:43 PM
I keep seeing this hash in the "prev_block" field in the data of the work that I get from deepbit.net :
These are 8 zeros there (4 bytes = 32 bits). Real blocks as I see on block explorer have 47 zero bits, I think? Is this block from the "testnet"? This isn't for real?
Quote
b84401536a5ec2fca283157d1ba9b80c0259a63954659d20000113dd00000000
These are 8 zeros there (4 bytes = 32 bits). Real blocks as I see on block explorer have 47 zero bits, I think? Is this block from the "testnet"? This isn't for real?
February 26, 2011, 10:14:09 PM
February 26, 2011, 10:11:17 PM
Code:
* Connection #0 to host www.deepbit.net left intact
JSON decode failed(1): '[' or '{' expected near '<'
json_rpc_call failed, retry after 30 seconds
Any ideas?
Wouldn't be surprised if the response was HTML (404 or 503 error) instead of JSON. Other than that not sure.
February 26, 2011, 10:10:38 PM
Code:
* Connection #0 to host www.deepbit.net left intact
JSON decode failed(1): '[' or '{' expected near '<'
json_rpc_call failed, retry after 30 seconds
Any ideas?
February 26, 2011, 10:07:19 PM
Code:
* Connection #0 to host www.deepbit.net left intact
JSON decode failed(1): '[' or '{' expected near '<'
json_rpc_call failed, retry after 30 seconds
Any ideas?
February 26, 2011, 09:45:51 PM
It can't be compared directly with 3% fee because it's 10% of unknown value for me. It may be more and may be less, comparing to proportional mode. If some block takes longer to find, this will be more than in Proportional.
I'm already 2 bitcents richer sucka! Should I spend it on crack or hoes, I wonder?
It's fun and interesting to try these things out :-)
February 26, 2011, 09:43:12 PM
Thanks for building a competing mining pool to those out there. I will try yours because although the fee is 50% higher that the one I currently use gives me alot of "invalid or stale" and occasional "Problem communicating with RPC", which by rough calculations, amounts to much higher than your 3%. I do suspect that these problems may be on my end, so don't consider this a negative or anyone elses mining pool. However, I will try your pool and report back. 4 5970's.
February 26, 2011, 09:13:41 PM
That's actually really important! That's a 10% (statistical average) fee instead of the 3% fee for "Proportional" that you mention in your first post.
I don't think the 10% is out of line, just that it is important that it be disclosed as different.
Price per share is given with high precision, so it wasn't a secret.I don't think the 10% is out of line, just that it is important that it be disclosed as different.
As you know, it's the same as in other pool, so i decided that it's suitable rate.
It can't be compared directly with 3% fee because it's 10% of unknown value for me. It may be more and may be less, comparing to proportional mode. If some block takes longer to find, this will be more than in Proportional.
February 26, 2011, 09:09:26 PM
I don't see such an option. I also don't understand the "Minimum value for automatic payment" option. Is there an automatic payment whenever the balance reaches this value?
Open your account page, scroll down to workers list, click on worker name and you'll see it's configuration.After finishing tests, payments will be sent every hour if it's more than given threshold.
Also, at the top, with green letters is a "0.00 MH/s" label about "Average speed". I know that my client is calculating hashes at around 1Mh/s, but it's not reporting it to you. Is there some protocol for doing that? I can't find any good documentation for this "standard" getwork protocol. I had to read code and packet dumps.
Actually it's a luck meter, it just counts number of received shares per given time interval. If it shows, for example, 10 MH/s, then at this moment you are just as lucky as someone with 10 MH/s speed.Currently it's set to 7 minutes, which is shorter than interval between your shares.
February 26, 2011, 09:04:30 PM
Now you can try some new exciting feature - optional Pay-Per-Share mode is enabled in my pool. You can choose payments method for any of your workers, look at your account page for workers configuration.
Current rate is 0.0012342331201539 BTC per share.
Current rate is 0.0012342331201539 BTC per share.
I don't see such an option. I also don't understand the "Minimum value for automatic payment" option. Is there an automatic payment whenever the balance reaches this value?
Also, at the top, with green letters is a "0.00 MH/s" label about "Average speed". I know that my client is calculating hashes at around 1Mh/s, but it's not reporting it to you. Is there some protocol for doing that? I can't find any good documentation for this "standard" getwork protocol. I had to read code and packet dumps.
Jump to: