[DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too

[[Tycho]]

My miner logs start to show a small rate of failed RPCs ... out of curiosity,
(and unless it's a trade secret :) ) do you load balance the incoming RPC stream
to multiple instances of the C++ bitcoin daemon ? If so, can you tell us what's
your load balancing strategy (i.e. how many RPC/s do you send to each instance)

Actually i don't need load balancing at this moment. My tests showed that one instance will be enough for much more users.
I have some plans for this, but there are no problems with it yet.

I'm mining in my pool myself and don't see any RPC failures, except for some moments when pool software was updated. Are you sure it's not a problem with your connection ? You can run a ping -t deepbit.net and look if there is packet loss at the same time with RPC failures.

[paulofisch]

Sorry, the number of bits is 32. My mistake. I'm new. The probability is one in 2^32. Should take around 5-6 hours on average if that hash rate is correct.

The benchmark/avg. is currently 1 share every 5 minutes at 14200Kh/s.
At your rate of around 100Kh/s you should see a hit every 11-12h by my count.

If the RPC failures increase, check you have the latest clients that persist connections nicely, rather than fire-hosing the server with connection attempts :-)

And hi and welcome etc.

[prcarter]

The benchmark/avg. is currently 1 share every 5 minutes at 14200Kh/s.
At your rate of around 100Kh/s you should see a hit every 11-12h by my count.

If the RPC failures increase, check you have the latest clients that persist connections nicely, rather than fire-hosing the server with connection attempts :-)

You are right. I was wrong again. When that is the hash rate, one can expect solutions every that often. Now I have a 1Mhash/sec rate (gcc -O3) so I should get solutions approximately every 70 minutes.

There wasn't one single correct thing in what I posted! No, there was!

For the "fire-hosing" problem, I simply reduced the "getwork" call frequency from once every 5 seconds to once every 20 seconds.

[paulofisch]

*snip*
At your rate of around 100Kh/s you should see a hit every 11-12h by my count.

If the RPC failures increase, check you have the latest clients that persist connections nicely, rather than fire-hosing the server with connection attempts :-)

You are right. I was wrong again. When that is the hash rate, one can expect solutions every that often. Now I have a 1Mhash/sec rate (gcc -O3) so I should get solutions approximately every 70 minutes.

There wasn't one single correct thing in what I posted! No, there was!

For the "fire-hosing" problem, I simply reduced the "getwork" call frequency from once every 5 seconds to once every 20 seconds.

Not wrong, just learning, and quickly :-)

The fire-hose thing was more of a problem with the official client until recently and applies less to what you're doing I think.

[[Tycho]]

In other words, if your own miners are on the same LAN,
(or very close-by from a latency P.O.V.) your failure rate
will be much lower than that of someone who is 300ms
away.

Actually no, i'm 144 ms away from DC :)

[[Tycho]]

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.

[NicholasBell]

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.

I'm curious, being new to pooled mining--what is the motivation for choosing one mode over the other? Is it to remove some of the luck component?  I can see that maybe if the pool as a whole is really unlucky and doesn't solve a block then each share in "proportional" would be worth less than if the pool solves it faster.

Does the current pay rate you have there represent the statistical average rate we would expect in proportional mode anyway?

[[Tycho]]

Now you can try some new exciting feature - optional Pay-Per-Share mode is enabled in my pool.

I'm curious, being new to pooled mining--what is the motivation for choosing one mode over the other? Is it to remove some of the luck component?  I can see that maybe if the pool as a whole is really unlucky and doesn't solve a block then each share in "proportional" would be worth less than if the pool solves it faster.

Does the current pay rate you have there represent the statistical average rate we would expect in proportional mode anyway?

Depends on people. Some just like getting their cents now, some can wait. Some feel lucky and some - not.
Price is calculated as (50 / current difficulty) - 10%, exactly as other pay-per-share pools, just some nano-coins more because of higher precision :)

[xenon481]

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.

I'm curious, being new to pooled mining--what is the motivation for choosing one mode over the other? Is it to remove some of the luck component?  I can see that maybe if the pool as a whole is really unlucky and doesn't solve a block then each share in "proportional" would be worth less than if the pool solves it faster.

Does the current pay rate you have there represent the statistical average rate we would expect in proportional mode anyway?

Yes, with a Pay-Per-Share model (like BitPenny), the vast majority of the variance is moved from the individual miner client to the pool operator. In this mode, the pool operator is betting (like a casino) that the statistical average number of shares to solve a block will hold true over time. As casinos prove, this is a near certainty over time unless somebody finds a way to cheat and skew the statistical average.

It also moves the risk of being harmed by cheaters from the miners to the pool operator.

[xenon481]

Now you can try some new exciting feature - optional Pay-Per-Share mode is enabled in my pool.

I'm curious, being new to pooled mining--what is the motivation for choosing one mode over the other? Is it to remove some of the luck component?  I can see that maybe if the pool as a whole is really unlucky and doesn't solve a block then each share in "proportional" would be worth less than if the pool solves it faster.

Does the current pay rate you have there represent the statistical average rate we would expect in proportional mode anyway?

Depends on people. Some just like getting their cents now, some can wait. Some feel lucky and some - not.
Price is calculated as (50 / current difficulty) - 10%, exactly as other pay-per-share pools, just some nano-coins more because of higher precision

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.

[prcarter]

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.

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.

[[Tycho]]

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.

[[Tycho]]

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.
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.

[ronaldmaustin]

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.

[paulofisch]

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 :-)

[telestrial]

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?

[[Tycho]]

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?

Which miner do you use ? It this a consistent error ?

[paulofisch]

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.

[telestrial]

I'm using the newer CPU miner...

http://bitcointalk.org/index.php?topic=1925.60

[prcarter]

I keep seeing this hash in the "prev_block" field in the data of the work that I get from deepbit.net :

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?