[1423GH] ABCPool PPS - Proxy Pool For High & Steady Mining Rewards

[rTech]

In what timezone ABCPool is located. I really want my coins out

[MintCondition]

In what timezone ABCPool is located. I really want my coins out

In approx. 90 minutes we'll deploy payout-address locking.  At that moment payouts will be enabled again.

[MintCondition]

UPDATE: Payouts enabled, Address-lock and HTTPS now available for extra security.

The new stuff: Payouts are enabled again; maximum auto-pay trigger has been limited to 5 BTC to discourage large balances. We've also just deployed a payout-address locking facility, accessible from the 'My Account' section.

The theme for us for the past few days has been Security, security, security:

History of events
Last Thursday we discovered a security flaw which was being exploited. An attacker was transferring the balances of multiple accounts to his own Bitcoin addresses without consent or awareness of the respective account holders. This happened over a period of approximately one week. Some accounts listed multiple fraudulent transactions over several days. Initially this went on unnoticed, but then Thursday two users notified us of suspicious payments in short succession. This triggered us to halt all payments immediately and launch an investigation. After some nifty digital forensics we concluded that session spoofing was the attack vector. As an aside, doing forensics is quite fun but a lot less so when it concerns your own systems!

Vulnerability patched
The leak was patched soon after locating it, and we started inventorying the scale of the damage (affected accounts, time period, amounts). We are now asking everybody that has been affected to PM us the details, so we can work out a way of compensation.

SSL/HTTPS now available
The event also inspired us to adopt some extra security measures. We added HTTPS support to the site earlier this weekend, encrypting your communications with the pool through a self-signed certificate (see our FAQ for details).

Payment address locking now available
And now today we've added the address locking facility, which allows you to permanently lock your payment address. Payouts from locked accounts can only be made out to the address specified. The address can not be changed if a hacker were to somehow compromise your account, or even perform a SQL injection. The permanence is both the upside and the downside of the lock: An intruder cannot change the destination address, but neither can you.

ABCPool back to full strength
With this trifecta of improvements we are confident that ABCPool now offers the security needed to resume payouts. Therefore we'd like invite those that understandably took a break from ABCPool: You may point your miners to pool.ABCPool:8332 once again!

NB: About the PIN mechanism: We feel PIN in its current incarnation never added a lot of security. We might remove it down the road, or rework it into something better.

[MintCondition]

As a precaution, we strongly urge you to change your password if it's not very strong. The possibility exists that weak passwords have been brute-forced by the intruder through the abuse of the password-change functionality.[/b] Also, never re-use the account password for your workers: the worker passwords are stored & sent unencrypted.

[Brian DeLoach]

Initially this went on unnoticed, but then Thursday two users notified us of suspicious payments in short succession.

I actually noticed it much sooner. Not having the payout history is a security flaw in itself and prolonged the attack. I noticed immediately that something was wrong early October 29th, but either thought the pool was down, the shares were not being calculated correctly, or my balance somehow got payed out automatically to my wallet (I didn't check, I was busy). I never even considered someone else was draining the account. But, with no way check where the funds went, I didn't say anything, and the attacker got five more days to steal people's bitcoins until November 3rd. I highly suggest keeping payout history for everyone, allowing quicker discovery of a hack.

On the bright side, hashing rate has returned back to normal. I still think this pool is the best around, and it's only a matter of time before it'll be in the top 3 (BTCguild and especially deepbit are hard to shake).

[MintCondition]

Initially this went on unnoticed, but then Thursday two users notified us of suspicious payments in short succession.

I actually noticed it much sooner. Not having the payout history is a security flaw in itself and prolonged the attack. I noticed immediately that something was wrong early October 29th, but either thought the pool was down, the shares were not being calculated correctly, or my balance somehow got payed out automatically to my wallet (I didn't check, I was busy). I never even considered someone else was draining the account. But, with no way check where the funds went, I didn't say anything, and the attacker got five more days to steal people's bitcoins until November 3rd. I highly suggest keeping payout history for everyone, allowing quicker discovery of a hack.

On the bright side, hashing rate has returned back to normal. I still think this pool is the best around, and it's only a matter of time before it'll be in the top 3 (BTCguild and especially deepbit are hard to shake).

As an experiment we decided to ask for a donation to use the features added over the past month, to see how that would affect donation rates. Payment history is now freely available again. You're right to say that security is increased by being able to check payment history. It's a good argument to keep at least some form of history available for free.

I think we might be able to come up with a compromise that does not give all info right away, but enough to notice that something is wrong. Like listing only the addresses and their period of use for all your payouts.

Until we have figured out how to do that without it impacting security, we'll leave access to the payout history unrestricted.

[Hotdog453]

Initially this went on unnoticed, but then Thursday two users notified us of suspicious payments in short succession.

I actually noticed it much sooner. Not having the payout history is a security flaw in itself and prolonged the attack. I noticed immediately that something was wrong early October 29th, but either thought the pool was down, the shares were not being calculated correctly, or my balance somehow got payed out automatically to my wallet (I didn't check, I was busy). I never even considered someone else was draining the account. But, with no way check where the funds went, I didn't say anything, and the attacker got five more days to steal people's bitcoins until November 3rd. I highly suggest keeping payout history for everyone, allowing quicker discovery of a hack.

On the bright side, hashing rate has returned back to normal. I still think this pool is the best around, and it's only a matter of time before it'll be in the top 3 (BTCguild and especially deepbit are hard to shake).

As an experiment we decided to ask for a donation to use the features added over the past month, to see how that would affect donation rates. Payment history is now freely available again. You're right to say that security is increased by being able to check payment history. It's a good argument to keep at least some form of history available for free.

I think we might be able to come up with a compromise that does not give all info right away, but enough to notice that something is wrong. Like listing only the addresses and their period of use for all your payouts.

Until we have figured out how to do that without it impacting security, we'll leave access to the payout history unrestricted.

Enabling/disabling features via donation make sense, but it's a damn hard thing to do correctly. There's just... well, not that much to turn on and off to make it "worth it" or "not worth it" to donate. It's not like there's a massive, game-changing feature that can be turned on or off.

Personally, if and when you need more cash, just make a donation/fee mandatory, and never expect people to donate. I was one of the "biggest" contributors to the donation over at ARS, and I was STUNNED by that; I was doing a measely 2%. Some people will just never contribute, ever. And the people who do donate eventually feel used and such compared to those getting a "free ride" so to speak.

[Brunic]

I think the "donate and get features" model is viable and interesting.

Vitals features (like the payout history) should not be in that model. It needs to be free. I believe you make all the efforts to make this pool secure, but I like to verify by myself that everything is ok. Everything that concern transactions between us (the miners) and you (the pool) should be available for both sides. Like that, both sides can be sure they trade correctly.

One thing I would really be willing to pay for is stats, a lot of them. How much Bitcoins by day, hour, minutes? In relation to the GHash of the pools? Complete network power in real-time? My percentage of the total network? Future projections of how much I will make for the next two weeks? How many Bitcoins I make at that MHash rate at this difficulty?

You, as the pool, have access to a lot of raw data. If you can sort this data, and offer an access to a well-presented page of stats, you have a little gold mine here.

Having to pay for mining on a pool is retarded. I don't see why I need to pay somebody so he can see all my informations about mining while I can mine by myself. A pool process and transfer data so, you should see yourself as a data-processing company. And what a data-processing company do? They sell their data, with nice little charts, predictions, hard facts and whatever you can think of.

Here's how I see that:

Basic account - You mine with all the features needed for mining and for security of the transaction between the pool and the miner.
Cost: 0%

Stats account - You can access a vast quantity of data. You have all the popular statistics functions, with a bunch more added to it.
Cost: It depends on what you offer. You don't want to have a high price for low value, because nobody will take. Let's 1% for example.

Stats-junkie account - You have everything. A wet dream of statisticians. Sort of account where you can sort anything by anything, and even where you can access the "coming soon" features, where you can try them.
Cost: As always, it depends on what you offer. For the example, let's say you charge 3%. Like I said, it is an ultimate wet dream, for an ultimate price.

Even more, you could sell this to people who don't mine at ABCPool, but would be interested in seeing that data. For those guys, you ask for more, because they don't mine for you. You charge something like 20$/month to have an access to all those stats, with API, email, SMS, whatever they need of. If you do that, be sure that you put a ceiling on the price for the miners, so the big big big miners don't pay more than those who only buy data.

You're not a pool, you are a data-processing business. 

[likuidxd]

Any plans for a stats signature? I wouldn't mind changing mine
btcstats.net

[Nic Dooce]

And when do we will see the ''hall of fame'' stats ! Who's is the biggest ? About 20 000 Mhash I should guess...

[MintCondition]

Any plans for a stats signature? I wouldn't mind changing mine
btcstats.net

USERBARS: Twmz, owner of btcstats.net, was nice enough to create a userbar for ABCPool.co. Using your API key and BTCStats.net you can show off your hashrate! They look pretty cool:



Thanks Twmz!

Caveat Emptor: I'm not sure if it is still possible to put these userbars in your signature at bitcointalk.org, since they seem to have disabled sig-images for new signatures.

MC

[jamesg]

Any plans for a stats signature? I wouldn't mind changing mine
btcstats.net

USERBARS: Twmz, owner of btcstats.net, was nice enough to create a userbar for ABCPool.co. Using your API key and BTCStats.net you can show off your hashrate! They look pretty cool:



Thanks Twmz!

Caveat Emptor: I'm not sure if it is still possible to put these userbars in your signature at bitcointalk.org, since they seem to have disabled sig-images for new signatures.

MC

Maybe we can get TWMZ to turn these user "bars" into profile pic size images...

I would donate a few BTC if he did for his service.

[bal3wolf]

best pool so far i cant wait till winter hits here full time and i will get back to mining more.

[jamesg]

Looks like the pool went down after i started bringing my hash over. Sorry if i crashed the pool. 

[twmz]

Maybe we can get TWMZ to turn these user "bars" into profile pic size images...

I think the new foum policy is stupid.  I also think these didn't turn out as well as the standard userbar-shapped images (they are an awkward shape), but here you go:

Edit: Nevermind, I think the forum actually forces them to be an even more awkward shape and so these would get stretched badly.  I can't test it at the moment, be cause I can't change my avatar without losing my current sig image and I don't want to do that.   I'll have to try working on it again later.

[Eveofwar]

Maybe we can get TWMZ to turn these user "bars" into profile pic size images...

I think the new foum policy is stupid.  I also think these didn't turn out as well as the standard userbar-shapped images (they are an awkward shape), but here you go:



Go back to http://btcstats.net to lookup your avatar URL

Care to elaborate (emphasis mine) ?

[Brian DeLoach]

I think the new foum policy is stupid. 

Care to elaborate (emphasis mine) ?

theymos (administrator) disabled images in signatures.

[Eveofwar]

I think the new foum policy is stupid. 

Care to elaborate (emphasis mine) ?

theymos (administrator) disabled images in signatures.

Interesting...so I guess people can't "add" new images...but those who have already done so prior, are not at the mercy of this new policy ?

[Brian DeLoach]

Correct. Anyone who has one right now can't modify their signature or they'll lose it.

[MintCondition]

Looks like the pool went down after i started bringing my hash over. Sorry if i crashed the pool. 

It's always a good stress-test for a pool when you come around

Regarding the instability when you joined: The limit for the number of open filedescriptors for the pool backend was still in its restrictive default. That number also governs maximum TCP connection count.

We were already seeing some strange log readings, but you coming to knock on our door made us really hit the limit, and that's probably where it went wrong.

We've increased the limit to a more sensible value (60000) a few hours ago, and all indicators are back to normal.

Could you try again?