[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[kano]

Is there something we can do about invalids?  I know some time ago BTCGuild had a lot of invalids and they were able to lower them significantly somehow.  I know before these last few we were better than average, but I don't know if luck and averages really have to apply to invalids.  For instance, I'm wondering if members couldn't make sure their bitcoin client peers with the pool's bitcoind in order to help propogate the pool's blocks faster.

It's the time from the pool accepting the share to the bitcoind submitting it to the network
 (and of course how well connected bitcoind is to the network)
If that's got ANY delays in it, those delays of course increase the chance of an invalid/orphan.
Reducing those delays reduces the chance of getting an invalid/orphan.

[1714056181]

1714056181

[1714056181]

1714056181

[1714056181]

1714056181

[1714056181]

1714056181

[The00Dustin]

Is there something we can do about invalids?  I know some time ago BTCGuild had a lot of invalids and they were able to lower them significantly somehow.  I know before these last few we were better than average, but I don't know if luck and averages really have to apply to invalids.  For instance, I'm wondering if members couldn't make sure their bitcoin client peers with the pool's bitcoind in order to help propogate the pool's blocks faster.

It's the time from the pool accepting the share to the bitcoind submitting it to the network
 (and of course how well connected bitcoind is to the network)
If that's got ANY delays in it, those delays of course increase the chance of an invalid/orphan.
Reducing those delays reduces the chance of getting an invalid/orphan.

So, isn't there a way to tell the client to peer with certain addresses, and wouldn't this make the bitcoind on the pool server better connected to the network?  Then, assuming the backend is as tuned as it could be, wouldn't this help?  OTOH, maybe telling people the address of the bitcoind server would be a bad plan because it would allow for targeted attacks, and maybe too many peers would increase latency instead of speeding up propogation.  I'm just thinking aloud, that's all I was doing in my previous post.  Putting it out there for Inaba to consider, although, if I'm wrong, I don't mind being told.

[gnar1ta$]

Is there another pro BIP 17 pool out there?

At least pool.itzod.ru, and you can use BIP 17-patched bitcoind with p2pool. I think EclipseMC might support BIP 17 as well, but I'm not sure if they have the patch deployed live yet.

Inaba?

[cyberlync]

Is there something we can do about invalids?  I know some time ago BTCGuild had a lot of invalids and they were able to lower them significantly somehow.  I know before these last few we were better than average, but I don't know if luck and averages really have to apply to invalids.  For instance, I'm wondering if members couldn't make sure their bitcoin client peers with the pool's bitcoind in order to help propogate the pool's blocks faster.

I asked earlier if it would benefit anything (as in cut down stale shares, duplicates, etc. and perhaps even invalids) if the pool set up a VPN for the dedicated miners (possibly filtered so it's not abused), and possible with existing hardware without impacting the already running software performance. I don't really know enough, perhaps someone else does?

[kano]

Is there something we can do about invalids?  I know some time ago BTCGuild had a lot of invalids and they were able to lower them significantly somehow.  I know before these last few we were better than average, but I don't know if luck and averages really have to apply to invalids.  For instance, I'm wondering if members couldn't make sure their bitcoin client peers with the pool's bitcoind in order to help propogate the pool's blocks faster.

It's the time from the pool accepting the share to the bitcoind submitting it to the network
 (and of course how well connected bitcoind is to the network)
If that's got ANY delays in it, those delays of course increase the chance of an invalid/orphan.
Reducing those delays reduces the chance of getting an invalid/orphan.

So, isn't there a way to tell the client to peer with certain addresses, and wouldn't this make the bitcoind on the pool server better connected to the network?  Then, assuming the backend is as tuned as it could be, wouldn't this help?  OTOH, maybe telling people the address of the bitcoind server would be a bad plan because it would allow for targeted attacks, and maybe too many peers would increase latency instead of speeding up propogation.  I'm just thinking aloud, that's all I was doing in my previous post.  Putting it out there for Inaba to consider, although, if I'm wrong, I don't mind being told.

Yeah that's why I put it in brackets - coz it was what you said (and the risk you mention)

It could certainly help if everyone did - but the risk ... I guess if the bitcoind didn't actually contain the wallet - but simply posted the blocks it would only be a ddos risk - and then that's not really an issue coz you could move it pretty quickly if the pool is easy to redirect to a different bitcoind ... hmm and if you modified bitcoind to ignore requests that didn't alienate it on the network then having lots of connections might be OK ... OK I'm thinking out loud now ... I better stop rambling

[wolf902]

There is a 10% fee..

[Inaba]

That particular bitcoind maintains about 80 - 100 connections at any given time. I guess I could try to track down the public ups of the other pools bitcoind and explictly specify them.

I will try to do that tomorrow.

As far as hip 16/17 goes I will make an announcement with regards to that tomorrow that should satisfy everyone.

[iNs4nePT]

There is a 10% fee..

You could at least add the whole details. The fee is for cashing out Unconfirmed BTC, and when there is the possibility that a recent block is invalid, i can only consider that fee fair (otherwise the pool would have to pay for the missing BTC).

Why not just wait until everything is confirmed?



Also, i am taking the chance to thank Inaba for all the features that make EMC great.

I am donating a tiny % of my measly 240Mh/s, and hope everyone considers donating something as well.
Every bit helps, i guess...

[NetworkerZ]

My 5% donation time is still running! Hope other will do so too, at least for a few days!

Greetz
NetworkerZ

[stiftmaster]

It´s a joke, or

Private    165333  15:31:29   2012-02-04    05:16:01    1802362    27.08%   Invalid    12399    0    0.00000000

I´m waiting for the 3rd invalid block this day....

[mmbregman]

2012-02-04 17:12:29: Listener for "Default": us.eclipsemc.com:8337 04/02/2012 17:12:29, Unexpected error:

Getting this for a while now, on every server I tried to log to.. 

[NetworkerZ]

My Miners are wokring correctly! But 3 invalid Blocks on two days ... 

[Inaba]

You know, all these invalids started happening after the P2SH thing.  I am making changes to the bitcoind daemons today, we'll see if that makes any difference, though I can't imagine what it could be other than bad luck.

mmbregman: What miner are you using and you say us2 and us3 are also giving you the same error?

[omo]

is it possible to use both DGM and PPS(with fees) payout scheme? just like deepbit

[Inaba]

It's possible and it's something I have been considering.  I will be looking into something like that in the next couple weeks.

Paypal payments should be working again, for those having issues.

[freshzive]

Another invalid?

We were just starting to get on a roll with a reasonably quick blocks

[mmbregman]

You know, all these invalids started happening after the P2SH thing.  I am making changes to the bitcoind daemons today, we'll see if that makes any difference, though I can't imagine what it could be other than bad luck.

mmbregman: What miner are you using and you say us2 and us3 are also giving you the same error?

I'm using GUIminer.. us3 is giving me  upstream RPC error, the rest just "Unexpected error"

[Inaba]

I was working on US3 just now. It should be back to normal.

Something is wrong with your CGminer or the configuration.  "Unexpected error" isn't very helpful.  One of the many reasons I dislike cgminer.  It would be great if it just did simple things properly, but the lack of ability to split GPUs by miner and errors like that just turn me off to it almost completely.

[mmbregman]

So what miner should I use to mine with a GPU (6950)?

[Inaba]

I use poclbm for the most part.