Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 43. (Read 379078 times)

 couldn't a pool operator just allow 25-50 (more?) trusted IPs to connect to his bitcoin
daemon and stop this attack cold? yes.. they need to broadcast the found block ASAP
but they could just say it to 50 nodes who they know who they are, geographically located
in strategic places, etc... i am sure digging up a list is not too hard especially if pool operators
cooperated a bit..

and i really do not know how ping (icmp) will compare to a bitcoin client saying i found a block...
there might be a lot of variance in that considering icmp is given pretty low priority on most backbone
routers and what not... and a pool operator could just not allow it period. so you will end up pinging
their default gateway at the ISP or a machine close to them in the same subnet perhaps.

if it were ms i KNOW it will work
i just have to include ping times...

yup. i was just reading about that. at first glance it does seem like it could work.
in practice i am not sure. one is talking about milliseconds being the determining factor
in deciding when to switch.

The hub mode patch is probably sufficient.

They have scratched out their donation link. Guess they were using other pools and BTC Guild to determine when to  hop on Deepbit.

http://fasthoop.appspot.com/

Update: deepbit support is only provided to donators(only valid before btcguild's change).

somebody said you could detect it through bitcoin itself.

just patch your bitcoin to do > 100 or more connections.
when a new block is announced have a look at the sender.

if the first announce came from btc guild its most likely their block.

its not my idea. but i am currently thinking about writing a patch for bitcoin.

why is closing/removing the pool the only way to stop pool hopping?

i asked this question to tycho over in his thread about deepbit. My question is underlined while
tycho's response is in bold.

tycho,

i have been reading that some people claim there is a way to use your pool as one of the pools for a pool hopping
strategy. specifically it was this website making a claim but naturally they demand a donation to get in on the "secret".

http://fasthoop.appspot.com/

based on my understanding of how your pool delays stats i am not quite figuring out how they can do this.
are they assuming if a block is solved and they cannot figure out who did it via screen scraping or an api.. it
must be deepbit?

or do you possibly know something i do not?

There are some possible options, but usually they don't give 100% true resuts.
The fact that they don't show it for everyone is a bit suspicious, by the way.

All pool hashrate jumps and dips are visible to me, so if poolhopping will cause a considerable loss for my users, I'll take appropriate actions.


based on that.. now that btcguild and deepbit both delay stats.. i am going to bet the possible options that
tycho mentions are even worse now percentage wise until i figure out otherwise. i have some ideas about this but i am still
reading and looking for hints which i think i found in another thread.

-------
oh. look at this. fasthoop.appspot.com just changed up their text on the website:

"Update: deepbit support is only provided to donators(only valid before btcguild's change). PM techwtf at forum.bitcoin.org for more details. The data may not accurate if pool is DDOSed.
Latest update: btcmine data is temporary unavailable"

it appears they were making an assumption if a block was solved it must have been deepbit. that is now broken as the
results were not as desirable as before.

now in the same thread about pool hopping the ideas they are coming up with are no where near as reliable.

Added the ability to turn idle miner warning emails on/off for individual workers.  Mostly for those who are mixing CPUs with their GPU mining.

I dont know what I was thinking when I wrote this. For some reason I though the dealy started counting when the round started...  

LOL


I agree his name is hard to spell, but...

http://en.wikipedia.org/wiki/Urethra

is slightly different than

http://www.eleuthria.com/image/site/logo.png

my 2 bitcents.

since the implementation of the delayed stats, my rewards have been scarily stable.  I get the same rewards for the really short blocks or the really long blocks. (~.13)

before the delayed stats, the very short blocks would range from .03 to .18 .  I can only assume the variance was caused by many miners hitting the pool at the beginning of the short block.  

I'm sticking with the guild, and keeping my donate at 5%.


edti:  elue:  any chance on adding the ability to set a local timezone for displaying times?  apparently I cannot subtract 5 hours in my head...  or is it 4 lol

I think Eleuthria has proven 100x over that he isn't just in this for the money and cares about the pool and the BTC community. There has been no pool that has so transparently and effectively dealt with exponential growth, DDOS attacks, etc.

I see no possible reason why having to wait an hour past finding a block to get paid would be problematic.

In any case, another +1000 to Eleuthria and BTCguild.

He gained a 2.5% donator right here.

+1

soon all pools will have some sort of protection against hopping. for most people having to manage hopping thus making minig even more complicated is just a bothersome hassle.

Mmmh, 2 weeks ago, eleuthria said to me, he wont do anything against pool hopping, Congratz to changing your mind. But i think he will loose a lot of donations, but in the end it is healthier for the pool.

Guess what? All you now got is less transparency, a time window of 1 hour for the operator to potentially grab a block for himself and to blame it on bad luck, worse features than before (no more instant payouts) and a new challenge for pool hoppers to still hop this pool.

As long as the payment distribution system doesn't change, these are the main reasons why I switched to better paying (no luck needed, no hopping possible by design, not hindered by "features") and more transparent (live stats) pools.

This btw. comes from someone who has a user ID of below 50.

If you look at page 1 of this thread: http://forum.bitcoin.org/index.php?topic=7760.msg113341#msg113341 I would say the strong argument against proportional is and was that it enables pool hopping and all migitations lead to less transparency and features while adding 0 value that another payout system like PPLNS wouldn't offer (PPLNS still pays out more if the pool is lucky with short rounds just like prop, it is MORE proportional to the hash rate than the proportional system and easily explained).

As however eleutheria risks loosing about ~100 GH/s * 43,5% = 43,5 GH/s from pool hopping (at least this is the amount mtRed is being hopped), his income will be reduced by this amount if he implemented proper hopping protection instead of implementing some "I am the god of this pool" measures that decrease features for everyone.

The more smaller pools switch back from the broken round proportional method to last N shares proportional, the easier it gets again to hop the pools that show wrong (=delayed) stats, especially if they are as huge as deepbit + btcguild.

BTCguild was already my favorite pool, and I've kept cards pointed at it as best as I can even during the DDoS and other problems.

Now that Eleuthria has actually done something about pool hopping, I like the pool even more. Especially since it was really clear that the decision was made carefully and not just a knee-jerk reaction to one person complaining or the like...

Everyone who's complaining? Aww, too bad, there's one less pool they can rip off the legitimate users from. Ignore them, Eleuthria! You've done the right thing for the majority of dedicated users. Let the complainers take their intermittent contributions to another pool.

You already did, thanks. I'm thinking about removing BTCGuild from the supported pools on my application, it has been a pain trying to support it. Random failure on retrieving data, sometimes it took over 20 seconds and i had to totally rewrite the update code only for that, API changed with no warning...

eleuthria, I have a big problem with your pool. Now that Idle Warnings are back, I'm also.

BUT: I cannot connect to uswest.

2005-01-10 15:34:12: Listener for "***" started
2005-01-10 15:34:13: Listener for "***": 10/01/2005 15:34:13, Setting pool *** @ uswest.btcguild.com:8332
2005-01-10 15:34:19: Listener for "***": 10/01/2005 15:34:19, Problems communicating with bitcoin RPC 0 2
2005-01-10 15:34:25: Listener for "***": 10/01/2005 15:34:25, Problems communicating with bitcoin RPC 1 2
2005-01-10 15:34:31: Listener for "***": 10/01/2005 15:34:31, Problems communicating with bitcoin RPC 2 2
2005-01-10 15:34:37: Listener for "***": 10/01/2005 15:34:37, Problems communicating with bitcoin RPC 3 2

I have no peerguard or any similiar or any other blocking software installed. Note that I can ping uswest.

No problem connecting to useast.... currently using that server but if you change that one to poing to the loadbalancer, too, I will be unable to mine on btcguild.

Thank you Eleuthria.
For all my critique earlier (and the math question is still out there),
I appreciate these latest changes. Thanks again.