Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: ekylypse on May 22, 2013, 09:27:58 PM



Title: [ATTN] Is your Pool a Scam?
Post by: ekylypse on May 22, 2013, 09:27:58 PM
Probably not; however, there are known issues with MMCFE, which is the most widely used front-end for pools. I have noticed that with several Alt coins(especially those with a low difficulty) MMCFE does not reward the users for some blocks.

Run this on your database to see if this is happening to you...

Code:
SELECT blockNumber AS unpaid_blocks FROM `winning_shares` WHERE blockNumber NOT IN (SELECT assocBlock FROM ledger)
The result here will check winning_shares against your ledger, and tell you which block numbers do not correlate.


Until I have a repair, and automatic payment method for these unpaid blocks I will be offering this list to the users of http://dgc.turbocoin.us and our other pools upon repair.

Maybe other operators can report back here from their various coins to see if particular coins have an issue or low difficulty, or low confirm requirements causes it.

Thanks.


Title: Re: [ATTN] Is your Pool a Scam?
Post by: Joerii on May 22, 2013, 09:30:16 PM
Great post. I have the feeling this is usefull for many of the pools out there, I always notice problems with crediting shares. Like you said, especially with your cryptocoins with low dif.


Title: Re: [ATTN] Is your Pool a Scam?
Post by: ekylypse on May 22, 2013, 09:59:15 PM
I wonder if the other pool ops will let us know...


Title: Re: [ATTN] Is your Pool a Scam?
Post by: ekylypse on May 22, 2013, 11:56:30 PM
bump for good measure


Title: Re: [ATTN] Is your Pool a Scam?
Post by: niteryder on May 23, 2013, 12:20:30 AM
Probably not; however, there are known issues with MMCFE, which is the most widely used front-end for pools. I have noticed that with several Alt coins(especially those with a low difficulty) MMCFE does not reward the users for some blocks.

Run this on your database to see if this is happening to you...

Code:
SELECT blockNumber AS unpaid_blocks FROM `winning_shares` WHERE blockNumber NOT IN (SELECT assocBlock FROM ledger)
UNION ALL
SELECT assocBlock AS unpaid_blocks FROM `ledger` WHERE assocBlock NOT IN (SELECT blockNumber FROM winning_shares)
The result here will check winning_shares against your ledger, and tell you which block numbers do not correlate.


Until I have a repair, and automatic payment method for these unpaid blocks I will be offering this list to the users of http://dgc.turbocoin.us and our other pools upon repair.

Maybe other operators can report back here from their various coins to see if particular coins have an issue or low difficulty, or low confirm requirements causes it.

Thanks.


Most pool ops should already know this along with how to properly use it in conjunction with estimate-pplns script.


Title: Re: [ATTN] Is your Pool a Scam?
Post by: ekylypse on May 23, 2013, 12:58:37 AM
Quote
Most pool ops should already know this along with how to properly use it in conjunction with estimate-pplns script.

Seriously? With the giant influx of pools, and no proper front-end for these alt coins, I highly doubt that everyone is playing by the rules...

EDIT: You run allpoolz, no? Did you run it on all/any of your pools?


Title: Re: [ATTN] Is your Pool a Scam?
Post by: niteryder on May 23, 2013, 01:05:05 AM
Quote
Most pool ops should already know this along with how to properly use it in conjunction with estimate-pplns script.

Seriously? With the giant influx of pools, and no proper front-end for these alt coins, I highly doubt that everyone is playing by the rules...

EDIT: You run allpoolz, no? Did you run it on all/any of your pools?

I use a slightly different query, but yes..  Thanks to mmcFE, I need to run this on all my pools.


Title: Re: [ATTN] Is your Pool a Scam?
Post by: Remember remember the 5th of November on May 23, 2013, 01:09:32 AM
Most of these issues come from not using Transactions.

Let's check this piece of code from mmcfe from Greedi's git.

Code:
if($isValidAddress){
//Subtract TX feee
$currentBalance = $currentBalance - 0.1;
//Send money//
if($bitcoinController->sendtoaddress($paymentAddress, $currentBalance)) {
$paid = 0;
$result = mysql_query("SELECT IFNULL(paid,'0') as paid FROM accountBalance WHERE userId=".$userId);
if ($resultrow = mysql_fetch_object($result)) $paid = $resultrow->paid + $currentBalance;

//Reduce balance amount to zero & make a ledger entry
mysql_query("UPDATE `accountBalance` SET balance = '0', paid = '".$paid."' WHERE `userId` = '".$userId."'");

                                 mysql_query("INSERT INTO ledger (userId, transType, amount, sendAddress) ".
                                            " VALUES ".
                                            "('$userId', 'Debit_MP', '$currentBalance', '$paymentAddress')");

$goodMessage = "You have successfully sent ".$currentBalance." to the following address:".$paymentAddress;
//Set new variables so it appears on the page flawlessly
$currentBalance = 0;
}else{
$returnError = "Commodity failed to send. Contact site support immediately.";
}
}else{
$returnError = "Invalid or missing Litecoin payment address.";

Let's look at this bit right here

Code:
if($bitcoinController->sendtoaddress($paymentAddress, $currentBalance)) {
$paid = 0;
$result = mysql_query("SELECT IFNULL(paid,'0') as paid FROM accountBalance WHERE userId=".$userId);
if ($resultrow = mysql_fetch_object($result)) $paid = $resultrow->paid + $currentBalance;

//Reduce balance amount to zero & make a ledger entry
mysql_query("UPDATE `accountBalance` SET balance = '0', paid = '".$paid."' WHERE `userId` = '".$userId."'");

                                 mysql_query("INSERT INTO ledger (userId, transType, amount, sendAddress) ".
                                            " VALUES ".
                                            "('$userId', 'Debit_MP', '$currentBalance', '$paymentAddress')");

So we see that our money gets sent before the balance is deducted. Depending on how PHP works, an attacker could execute a timely(albeit possibly very hard) attack and prevent
this code from executing
Code:
//Reduce balance amount to zero & make a ledger entry
mysql_query("UPDATE `accountBalance` SET balance = '0', paid = '".$paid."' WHERE `userId` = '".$userId."'");

                                 mysql_query("INSERT INTO ledger (userId, transType, amount, sendAddress) ".
                                            " VALUES ".
                                            "('$userId', 'Debit_MP', '$currentBalance', '$paymentAddress')");

Balance never gets deducted, attacker still has coins, depending on how often this attack can be done, a user can simply milk the pool till it's dry.

A simple solution to fix this would be to use Transactions, and instead of instantly querying bitcoin to send the coins, create a payment_queue in MySQL that a cronjob checks every few seconds and executes a few sendmany commands.

Funny note, prior to changing my nick to the current one, it was mcfe which I coined back in 2007ish waay before all this happened.


Title: Re: [ATTN] Is your Pool a Scam?
Post by: ekylypse on May 23, 2013, 01:21:10 AM
Most of these issues come from not using Transactions.

Let's check this piece of code from mmcfe from Greedi's git.
Code:
...
Funny note, prior to changing my nick to the current one, it was mcfe which I coined back in 2007ish waay before all this happened.

I suppose, then in an instance like this, if a timely attack were possible, what should happen to prevent it is:

1. Account balance is deducted
2. Run bitcoincontroller->sendtoaddress
3. IF bitcoinController returns false, account balance is re-credited with an error message indicating the failure.
4. ELSE, done.

Otherwise, listtransactions and compare them with send address, while not allowing more than 1 payout per (2 or 3)minute..