Bitcoin Forum
May 21, 2019, 10:08:49 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ATTN] Is your Pool a Scam?  (Read 1530 times)
ekylypse
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
May 22, 2013, 09:27:58 PM
Last edit: May 24, 2013, 11:09:41 PM by ekylypse
 #1

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.
1558476529
Hero Member
*
Offline Offline

Posts: 1558476529

View Profile Personal Message (Offline)

Ignore
1558476529
Reply with quote  #2

1558476529
Report to moderator
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558476529
Hero Member
*
Offline Offline

Posts: 1558476529

View Profile Personal Message (Offline)

Ignore
1558476529
Reply with quote  #2

1558476529
Report to moderator
1558476529
Hero Member
*
Offline Offline

Posts: 1558476529

View Profile Personal Message (Offline)

Ignore
1558476529
Reply with quote  #2

1558476529
Report to moderator
1558476529
Hero Member
*
Offline Offline

Posts: 1558476529

View Profile Personal Message (Offline)

Ignore
1558476529
Reply with quote  #2

1558476529
Report to moderator
Joerii
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile
May 22, 2013, 09:30:16 PM
 #2

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.

▼ Block Options.














   █
▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆
....The First Decentralized Binary Options Platform....
.........WEBSITE | WHITEPAPER | BITCOINTALK | TWITTER | FACEBOOK | SLACK | MEDIUM.....














   █
...PRE-SALE...
....Aug 1st, 2017....
ekylypse
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
May 22, 2013, 09:59:15 PM
 #3

I wonder if the other pool ops will let us know...
ekylypse
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
May 22, 2013, 11:56:30 PM
 #4

bump for good measure
niteryder
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
May 23, 2013, 12:20:30 AM
 #5

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.
ekylypse
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
May 23, 2013, 12:58:37 AM
 #6

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?
niteryder
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
May 23, 2013, 01:05:05 AM
 #7

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.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1001

Reverse engineer from time to time


View Profile
May 23, 2013, 01:09:32 AM
 #8

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.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
ekylypse
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
May 23, 2013, 01:21:10 AM
 #9

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..
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!