Donation rate below 0.5% again? Come on guys 
But yes, these 9 hour + blocks are deadly
But yes, these 9 hour + blocks are deadly
Killing me. I chose the wrong time to leave Deepbit. There is something to be said for low variance.
Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 144. (Read 499597 times)
January 30, 2012, 06:16:51 PM
Killing me. I chose the wrong time to leave Deepbit. There is something to be said for low variance.
January 30, 2012, 06:05:44 PM
Donation rate below 0.5% again? Come on guys
But yes, these 9 hour + blocks are deadly
But yes, these 9 hour + blocks are deadly
January 30, 2012, 04:58:46 PM
Yeah, we really have no luck these days!
Greetz
NetworkerZ
Greetz
NetworkerZ
January 30, 2012, 04:50:28 PM
LOL I come back mining on this pool and it seems to have the worse luck ever as of late....eek .. =/
Heres to better luck! =)
Heres to better luck! =)
That wasn´t lucky
2012-01-29 19:48:53 8139891
January 30, 2012, 01:34:07 PM
LOL I come back mining on this pool and it seems to have the worse luck ever as of late....eek .. =/
Heres to better luck! =)
Heres to better luck! =)
January 29, 2012, 10:09:35 PM
I actually had a white list IP thing in place back when the pool first started, meant to somewhat mitigate DDoS attacks, but it didn't really work out for some reason. I think instead of charging by the IP, maybe increasing by lack of efficiency would be a better solution. If someone is requesting 10 getworks and only returning 2 of them, that's kind of a problem... whereas if you have 100 miners and request 200 getworks and return 180 of them, that's much more acceptable.
Interesting, clever idea.
January 29, 2012, 03:11:01 PM
Stick with your instincts inaba. I don't know shet about running a pool, but I bet it's similar to running rigs, don't make any major changes until it is obvious there are solid advantages an things are stable. Same with the pool, 100% up time is what it's all about, stable, stable, stable.
Let the rest of these clowns work out the bugs.
Do what you're comfortable with, you're not making enough off this to make it stressful. This is supposed to be a fun and lucrative hobby for you.
I hope the 3% donation drive is still going on and growing.
Let the rest of these clowns work out the bugs.
Do what you're comfortable with, you're not making enough off this to make it stressful. This is supposed to be a fun and lucrative hobby for you.
I hope the 3% donation drive is still going on and growing.
January 29, 2012, 11:07:59 AM
Should be fixed now ... not sure what happened there, the bitcoind wasn't responding properly. Grr this is why there needs to be proper testing before deployment.
January 29, 2012, 09:16:39 AM
Why validity of more recent block are higher then late blocks?
Block 164217 (441) has validity 100/120
and
Block 164243 (443) has 112/120
BTW for block 164217 there are a chain up to 164354 (more then 120 blocks)
seems blocks 164217 (441) and 164223 (442) are stuck with 100/120 and 94/120 confirmations at the time of this post and still counted as unconfirmed BTC Block 164217 (441) has validity 100/120
and
Block 164243 (443) has 112/120
BTW for block 164217 there are a chain up to 164354 (more then 120 blocks)
January 29, 2012, 09:13:31 AM
man that last block was very fckn unfriendly
January 29, 2012, 05:51:55 AM
Why validity of more recent block are higher then late blocks?
Block 164217 (441) has validity 100/120
and
Block 164243 (443) has 112/120
BTW for block 164217 there are a chain up to 164354 (more then 120 blocks)
Block 164217 (441) has validity 100/120
and
Block 164243 (443) has 112/120
BTW for block 164217 there are a chain up to 164354 (more then 120 blocks)
January 29, 2012, 01:44:05 AM
Unfortunately I don't think that's going to apply to EMC, since I had disabled the P2SH announce on block creation due to the fact that there was no guarantee of support at any given time from blocks created on EMC. I don't think there's any way for Gavin to deduce which blocks were affected from EMC... but I could be wrong about that. The whole situation gives me a headache.
January 29, 2012, 01:00:33 AM
And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.
Gavin has pledged to personally reimburse all lost transaction fees and quickly fix the problem (he may or may not have done this already). January 28, 2012, 11:49:38 PM
I actually had a white list IP thing in place back when the pool first started, meant to somewhat mitigate DDoS attacks, but it didn't really work out for some reason. I think instead of charging by the IP, maybe increasing by lack of efficiency would be a better solution. If someone is requesting 10 getworks and only returning 2 of them, that's kind of a problem... whereas if you have 100 miners and request 200 getworks and return 180 of them, that's much more acceptable.
I'm still evaluating different options - I may try Eloipool, since it would be the easiest to work with with regards to DGM as implemented on EMC.
And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.
I'm still evaluating different options - I may try Eloipool, since it would be the easiest to work with with regards to DGM as implemented on EMC.
And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.
January 28, 2012, 11:01:44 PM
I've been thinking about something for some time, and perhaps I should ask others that know better than me.
If the pool set up a VPN for dedicated miners (perhaps filter it somehow so it's not used to stream hulu or whatever), could that improve the stale share count etc? Is it viable in any way with existing hardware or would the increased cpu/memory/bandwidth load require a separate server (and with that, rising running costs etc)?
If the pool set up a VPN for dedicated miners (perhaps filter it somehow so it's not used to stream hulu or whatever), could that improve the stale share count etc? Is it viable in any way with existing hardware or would the increased cpu/memory/bandwidth load require a separate server (and with that, rising running costs etc)?
January 28, 2012, 10:59:02 PM
longest block we had in a while, lets get it found and move on
January 28, 2012, 04:48:09 PM
Idea:
How about charge 5% auto to anyone who uses , um lets see 100-1000000+ Ip's
I think this would be a good offset to da botmastaz, they prolly don't care much and with all the extra traffic and load I think they should prolly pay a fee.. and I don't think they would mind too much
can split fee 2.5% to urself and 2.5% to miners who use less than 100 IPs
everyone is happy!
rejoice! huzzah!
How about charge 5% auto to anyone who uses , um lets see 100-1000000+ Ip's
I think this would be a good offset to da botmastaz, they prolly don't care much and with all the extra traffic and load I think they should prolly pay a fee.. and I don't think they would mind too much
can split fee 2.5% to urself and 2.5% to miners who use less than 100 IPs
everyone is happy!
rejoice! huzzah!
Good Idea,
but if each bot-member has his own ip, the criterion should be the the number of workers per user
January 28, 2012, 03:03:01 PM
This is only shown, when you refresh in that moment a block is solved and a new one starts. Must be a "maximum" number belonging to a lib or something. If you add a new worker, and don't use it, the maximum number at "Last Activity" is 15367 too ;-)
Greetz
NetworkerZ
Greetz
NetworkerZ
January 28, 2012, 12:22:11 PM
Round Duration 15367d 16:21:02
Ouch!
Ouch!
January 28, 2012, 12:06:18 PM
Perhaps the "admins" of an illegal mining botnet?!?
Greetz
NetworkerZ
Greetz
NetworkerZ
Jump to: