Topic: [1423GH] ABCPool PPS - Proxy Pool For High & Steady Mining Rewards - page 30. (Read 151781 times)

6 in the last 500,000 , most very small....

Tycho says most of them are from people using a copy of the same wallet on a different computer without scanning or something like that. He says most of them are not a threat. I still think the number is alarmingly high.

Or ... you could attempt many double spends with way less than half the network hash power and one of those many attempts might succeed.

... Hmm lots of double spend attacks happening according to that link ....

I am not saying ABCPool is the one attempting the double spend. It is the one who is ultimately paying for all the hashing power from ABC (Not Goat but maybe his client).

All the hashing power adds up, ABCpool would need to rent power from deepbit+btcguild+slush to attempt a doublespend.

You really think the conspiracy is that deep?

Probably older than you but that is irrelevant. My point is thread count can show whether or not you have been vetted by the community.


Look at the double spends currently being attempted. What if the sold hashing power is going to the people attempting double spends? This is why there is an inherent problem with selling hashing power from a site that claims to be its own pool. It may not have been stated anywhere they were or were not mining their own blocks but it is implied.

No, you're taking the quote out of context by removing important details (such as relevant quotes). Though, admittingly, I misread your statement about BIP 16/17 support. Regardless, I agree with inaba. There isn't anything inherently wrong with redirecting the hashing power somewhere else from time to time. They never lied about it or explicitly stated they were mining the blocks themselves, nor have they admitted to pool hopping (the practice of mining for a pool at the start of a new block, in case you didn't know).


Honestly, how old are you?

Care to retract your statement? This is why post count is important. If you were talking BS people will have called you out for it.

Deepbit is also more resilient to DDOS then ABCPool. There are a number of different servers to connect to, not just one. So if one is under DDOS then you can still connect to another.

You complained that ABC pool couldn't defend against a DDoS, which no centralized pool in existence today is able to do.

Is post count significant to you?

I was looking back where you said you purchased mining power off abcpool. This means they are not mining their own blocks. Maybe you read it wrong but I didnt say anything about you and VIP. Looks like I read your most recent post wrong.

That explains why the posts that were on a given page changed. I thought it was strange.

My complaints prior were about reliability which was 100% accurate. I am just reading about them not mining their own blocks today. It was confirmed by goat. I have been teetering on the edge of leaving ABCPool for some time but this is the final straw for me.

Can someone explain to me how someone becomes VIP with 100 posts?

Tycho is taking the exact same approach. With your constant complaints (which are inaccurate) you hurl at ABC pool, I'm surprised you haven't left long ago.

I am not comfortable with the fact that mining power is being used to pool hop. I thought I was mining for ABCPool and not whatever pool they were hopping to. I think calling yourself a separate pool at this point is misleading. It should say somewhere on your site that you are not mining your own blocks.

Combine this with me not supporting BIP16/17 until further testing and it looks like I will be going back to deepbit. I hate that it is so big but at least they mine their own blocks.

As a side note, EMC has supported port 80 mining since August or so I believe.  Not PPS, but meh.

Hello all,

A post on a different subject this time: We promised you a post-mortem on the outage last week. So here it is!

Last week there was a DDoS attack that lasted for more than a day (jan-17 18:00 - jan-18 23:00 UTC). This post is to explain what happened, the way we handled it, and what the future looks like.

Without any prior experience in handling this kind of attack, we were essentially powerless to do anything about it at first. That did not stop us from trying, but the pool only resurfaced on the internet when the attack eventually ceased.

Now that we've got some experience and have done our research we can say we know a bit more about such attacks. That knowledge is not entirely comforting. As it turns out, there's things that can be done, but at a certain point an attack will just knock out your service completely.

There have been a number of insightful comments, especially from Brian and Eleuthria, that helped us and our users in understanding the situation and being realistic about possible solutions while we were busy trying to solve it. Thanks for chiming in everyone!

What we were seeing were traffic levels at least hundreds of times the amount we normally handle and from a large amount of different addresses. What happens in such a case is that the internet connection becomes completely saturated, causing random traffic to be dropped before it even reaches our servers. with no full request ever making it in, the server load is paradoxically zero.

Whitelisting known good addresses using the server firewall is useless, because the traffic never even arrives at the server: It's pushed out of the way by all the unwanted traffic. So you'd have to find a place further away from the server where the pipes are still thick, and do the filtering there.

Amazon provides a few limited ways to do filtering, and there are several badly documented practical obstacles you run into when using their methods to combat heavy traffic.

So what have we changed to combat possible future attacks? We don't want to give future attackers too much ammunition, but some of the improvements are:
* Load balancers for all traffic.
* 'Other' Changes in network setup.
* Reporting and blocking of inefficient workers.
* Longpoller prioritization based on efficiency (this will also help prevent stales during normal operation!)

NB: in this context, efficiency is defined as the ratio of shares received per work unit handed out.

An interesting thing to note is that blocking will only go into effect whenever the load becomes extreme.

With these features deployed we hope we will be better prepared the next time an attack happens, although we won't know for sure until then..

In the meantime, enjoy the renewed stability of ABCPool
happy hashing everyone!
MC

Watching.

Their forum activity shows you are correct SAC. Nevertheless, now ABCPool supports it too

He meant among PPS pools specifically. He did indicate some non-PPS pools support it. I haven't verified his claims.

Lots of pools do now