Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 139. (Read 903163 times)

How to withdraw the exact Bitcoin balance on BTCGuild without the dust round-off?

Links to prior convo are welcome.

Just to clarify shifts/share counts:

BTC Guild's shifts are cut off at a certain # of shares.  It's not a precise cutoff due to just how fast they come in, but at this time the cutoff is whenever the In Progress shift has 2,500,000,000 shares in it.  It will normally be 2.51-2.52b shares by the time the script officially records the shift.  This slight variation is factored in when blocks are rewarded so there is not any kind of penalty for a shift having slightly more or less shares.

The # of shares in a shift is manually increased, generally around the time of a difficulty increase, or alternatively when the pool sees a large increase in hash rate.  The target rate is that shifts are more than 40 minutes, less than 60 minutes, that way the PPLNS system fully matures (closes) shifts in under 10 hours.

===

When the pool is speeding up (which is almost always happening), you will generally see your share counts decreasing per shift each day, unless you're adding more speed to keep up with the pool growth.  This happens because the shifts finish faster.  It has no affect on your payout, since you're completing more shifts in the same amount of time.

When the pool adjusts the shift size, that's when you'll see an increase in shares per shift.  Again, just like when shifts speed up, it has no direct impact on your payout, you now have more shares per shift but complete fewer shifts in the same amount of time.

===

The target rate of 40-60 minutes was decided on because it keeps the average blocks per shift (at neutral luck) at more than 10 blocks.  This number was chosen because the likelihood of a 10x difficulty block is *extremely* rare, meaning it's virtually impossible for the pool to have a shift that goes completely unpaid due to lack of block solves.  It also means the per share variance is reduced significantly compared to PPLNS pools that use a much lower 'N' value.  24-hour variance for a consistent miner really doesn't matter what the 'N' value is, but per-shift variance is what users tend to gauge the most, so keeping that as consistent as possible is the goal.

Hey Elu, I noticed something funny today after finishing the code to display API stats.

BTC Earned: 0.00259205
BTC Paid: 0.000
BTC Owed: 0.00259204

Not gonna cry foul over 0.00000001 lol but what's up with that ?

I KNOW you did not just touch the last slice of sausage n' onion !

or for us simpletons, same amount of pizza, now there are just more mouths around that pizza, and some have bigger mouths than others too....lol...

As he said it's the pools hash rate, but if you look at rankings you will see where you stand. If that number were to stay the same your payout might stay the same based on submitted shares, even as the pool rate increases. This assumes everyone who signs up has a lower rate than you. But, if the pool rate is increasing, and your ranking is dropping that to me anyway, means that people with higher hash rates than you are joining the pool, thus droppin you ranking and lowering payouts.

If everyone currently in the pool increased their hash rate but kept the same rankings, their payouts should be the same.

That's just my 2c but that's what I believe.

Basically, the lower (5 compared to 10) your ranking the better the payout should be and the adverse for a higher ranking being a smaller payout.

Got it.  Thanks!

A shift takes less time when the pools hash rate increases so you get fewer shares in that shorter period of time.

Probably my lack of understanding, but how is the amount of shares affected by hashrate?  I started with producing 40k shares per shift and now at 35k per shift average.  I know that # of bitcoin paid per share decreases by difficulty, but how is the number of shares produced decreased as well.  That is what I don't understand.

No.

It's because of the pools increased hash rate.

I am a N00b and a roofer, so not a lot of understanding on pools and bitcoin.  I started about a month ago and was mining about 40k shares per shift on pplns.  Now it is around 35k shares.  Is it because of old mining equipment?  BFL 60 gh/s and Red Fury 2.2 gh/s.  Any help on updating firmware or is this because of difficulty? shift ID 444424

Hey Elu, sent ya a PM about something regarding my BTCG API stats if you can gimme a quick bit of help on it... Thx.

Congrats on getting over 4PH/s

Yay indeed !

There's no chance of a Low Hashrate warning, the amount of calculations that would require is SIGNIFICANT since the pool does not actually track worker hash rates, only their shares over a certain time frame.  This may change in the future if I find a way to integrate hashrate tracking in the backends, but there are major problems with trying to do that when it comes to the same worker being present on multiple backend servers.


Also:  Fun fact...BTC Guild is around 23% of the network hash rate and just found 8 blocks in a row on the network.  This is after having a day with relatively terrible luck including multiple 2.5+ hour blocks.  Yay Variance!

Hey elu, in addition the the idle warning SMS / text message thing you said might take time to work on. I have another suggestion I was hoping you might consider implementing a bit sooner. Nothing like today mind you, just sooner then the other sugestion heh.

While I love the idle warning emails, I was wondering if you might add something like this.

Low hashrate warning: Mh/s

So if I'm running somehing that should always be doing about 600Mh/s and it starts hasing around 550Mh/s for say, 5 minutes... asuming my warning was 550Mh/s. Then I would get an email similar to the idle warning letting me eknow that worker x is hashing below the set threshold.

Only thing I see maybe being an issue is how much time must pass before said emails are sent but 5mins seems to be a standard on most pools with this feaure.

Edit: I just realized I stepped in it a little on this one, didn't consider it would have to be a per worker basis but would still lovee this feaure.

so assuming you went from a uint32_t to a uint64_t we're golden until diff approaches 18,446,744,073,709,551,615

There isn't much difference between the two other than latency.  Both of them are workin.  EU took a few extra minutes to fix due to the slower CPU on the validation server requiring more time to compile the new patch.

Having both of them added can help if you restart your miners or have frequent disconnects on your local connection.  Both VALIDATION servers have intermittent outages as botnets slam against them, occasionally causing packet loss or temporary additional DDoS filtering which may be likely to cause false positives.  This was part of why the EU server took a couple minutes longer to come back up as well.

Ive switched to the usa server and its working ok.

Whats the difference between the two anyway and is one better than the other?

I confirm that i can again connect to the servers.

Difficulty 2.19G (((