Bitcoin Forum
May 26, 2024, 07:55:24 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 »
81  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 09, 2011, 04:04:30 AM
Anyway this could very well have something to do with long polling.  I tried setting my max execution time (php.ini) to 1500 seconds, up from 30 seconds.  It did the following:

....

Any other ideas?
Hmm... run a packet sniffer and see what's going on with the LP request?
82  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 09, 2011, 03:03:54 AM
Thanks, that gets connected and accepting work now, but after maybe 3 minutes of mining, I see a random disconnect:
The long-polling request is probably getting terminated.  This should only happen if you have PHP's safe mode enabled -- set_time_limit() has no effect when running under safe mode, so the most likely cause here is that PHP is simply killing the script doing the long-polling request because it is running for too long.  (Note that the "disconnection" message comes almost exactly two minutes after the "connection" message.)

Try disabling safe mode.  Safe mode can only be disabled in php.ini or your Apache configuration; .htaccess files can not disable safe mode.
83  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 08, 2011, 08:15:49 PM
I love this one. It make switching really painless, especially after todays outage of slush's pool this proved a timesaver.
I'm glad you like it. Smiley

What I noticed however that the failing pool will still be asked for work, and only he doesn't return any, the next one will be asked. Are there plans for exponential backoff in order to avoid the extra request and the extra idle time? Just a mechanism to automatically blacklist a pool should it fail, and increase the blacklist time on each subsequent failure would be cool.
This is a good idea.  I've added it to the issue tracker.

The problem today is that slush sometimes gives me work, but does not accept the result (timeout/502 errors/...).
Hmm, I see.  I'll try to implement something so that if a pool doesn't respond normally to a share submission (e.g. it doesn't accept or reject the share, but gives some other HTTP or JSON-level error) the software will retry a few times, and disabled the pool for some time if it still can't reach the server.  This will depend on the other feature being implemented first.  (This one has also been added to the issue tracker.)

Also I get a lot of these:
Quote
192.168.3.5 - pilum [08/May/2011:19:21:43 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22"
192.168.3.5 - pilum [08/May/2011:19:21:45 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22"
192.168.3.5 - pilum [08/May/2011:19:21:47 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22"
192.168.3.5 - pilum [08/May/2011:19:21:49 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22"
192.168.3.5 - pilum [08/May/2011:19:21:49 +0200] "POST /index.php?lpurl=http%3A%2F%2Fdeepbit.net%3A8332%2FlistenChannel&pool=2 HTTP/1.1" 200 1181 "-" "Java/1.6.0_22"
Which makes me think that the diablo miner does not really take advantage of the long polling feature, and I start feeling bad for bombing pools with all those long poll requests. Any ideas?
Hmm, that is definitely weird.  Can you sniff those requests and paste the HTTP conversation (sanitizing authentication details) so that I can see what's going on?
84  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 08, 2011, 08:04:18 PM
This is the result, sanitized to remove portions of my email/password at deepbit:
Thanks, that's all I need to know to fix the problem.  Apparently the older PDO library doesn't support using the same query argument twice in a query.  A fix is forthcoming.
Fix just got pushed to the Git repository; please pull and see if the problem goes away.
85  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 08, 2011, 07:54:12 PM
This is the result, sanitized to remove portions of my email/password at deepbit:
Thanks, that's all I need to know to fix the problem.  Apparently the older PDO library doesn't support using the same query argument twice in a query.  A fix is forthcoming.
86  Bitcoin / Mining / Re: BitcoinPool.com open thread on: May 08, 2011, 04:15:11 PM
Our logs show otherwise, but either way, the last time you even participated in the pool was over a month ago and a considerable amount has changed since then.
This statement underlines the reason I decided to stop doing business with you.  There are a limited number of possibilities here.  You are either: lying, unable to tell what is true (logically incompetent), or, based on the incorrect logs, unable to write solid code (technically incompetent).  I'm sorry, but I do not trust my money with someone possessing any of these qualities.
87  Bitcoin / Mining / Re: BitcoinPool.com open thread on: May 08, 2011, 03:47:27 PM
Upset because we banned you for being inefficient?

It's a rule. You broke it.
What?  I left the pool voluntarily; my account was in good standing with over 90% efficiency.  If anything, it got banned for inactivity.  It might be a good idea to get your facts straight.
88  Bitcoin / Mining / Re: BitcoinPool.com open thread on: May 08, 2011, 03:30:07 PM
The only people who seem to dislike, distrust, or belittle our pool are those who haven't tried it themselves.
This is about the most laughable post I've read on this forum so far.  And I've read some of bobR's stuff...
89  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 08, 2011, 01:50:32 PM
That script returns "No rows found."

....

Based on my lay knowledge of php, I can't imagine why it doesn't return anything from the script you sent.
#$%&.  Me either... though I do have a few ideas...

Is it possible that my installation (default php 5.1 from CentOS 5.x with php-* installed, mysql-* installed, and the add-in json libraries) is different, misconfigured, or missing a dependency?  For reference, it already works fine with other popular MySQL/PHP off the shelf applications.
It should work fine.  I'm on PHP 5.3.3, but all my code should be compatible with most PHP5 versions (and probably some PHP4 versions too).

To further diagnose this, can you try this script now?

Code:
<?php

require_once(dirname(__FILE__) . '/common.inc.php');

header('Content-Type: text/plain');

$pdo db_connect();

function 
try_query($sql$args) {
    global 
$pdo;

    
$q $pdo->prepare($sql);

    if (
$q === FALSE) {
        return 
"Could not prepare statement (" var_export($pdo->errorInfo(), true) . ")";
    }

    
$result $q->execute($args);

    if (!
$result) {
        return 
"Could not execute statement (" var_export($q->errorInfo(), true) . ")";
    }

    
$row $q->fetch();

    if (
$row === FALSE) {
        return 
"No rows found";
    }

    
$q->closeCursor();

    return 
"Success (" var_export($rowtrue) . ")";
}

$queries = array(
    array(
'name' => 'original',
          
'args' => array(':worker_id'    => 1,
                          
':data'         => '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa'),
          
'query' => '
                SELECT
                    p.id AS pool_id,
                    wp.pool_username AS username,
                    wp.pool_password AS password,
                    p.url AS url

                FROM
                    work_data d,
                    worker_pool wp,
                    pool p

                WHERE d.data = :data
                  AND d.worker_id = :worker_id

                  AND d.pool_id = p.id

                  AND wp.worker_id = :worker_id
                  AND wp.pool_id = p.id
          '
),
    array(
'name' => 'hardcoded',
          
'args' => array(),
          
'query' => "
                SELECT
                    p.id AS pool_id,
                    wp.pool_username AS username,
                    wp.pool_password AS password,
                    p.url AS url

                FROM
                    work_data d,
                    worker_pool wp,
                    pool p

                WHERE d.data = '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa'
                  AND d.worker_id = 1

                  AND d.pool_id = p.id

                  AND wp.worker_id = 1
                  AND wp.pool_id = p.id
          "
),
    array(
'name' => 'nodup',
          
'args' => array(':worker_id'     => 1,
                          
':worker_id_two' => 1,
                          
':data'          => '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa'),
          
'query' => '
                SELECT
                    p.id AS pool_id,
                    wp.pool_username AS username,
                    wp.pool_password AS password,
                    p.url AS url

                FROM
                    work_data d,
                    worker_pool wp,
                    pool p

                WHERE d.data = :data
                  AND d.worker_id = :worker_id

                  AND d.pool_id = p.id

                  AND wp.worker_id = :worker_id_two
                  AND wp.pool_id = p.id
          '
),
    array(
'name' => 'no underscore',
          
'args' => array(':workerid'    => 1,
                          
':data'         => '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa'),
          
'query' => '
                SELECT
                    p.id AS pool_id,
                    wp.pool_username AS username,
                    wp.pool_password AS password,
                    p.url AS url

                FROM
                    work_data d,
                    worker_pool wp,
                    pool p

                WHERE d.data = :data
                  AND d.worker_id = :workerid

                  AND d.pool_id = p.id

                  AND wp.worker_id = :workerid
                  AND wp.pool_id = p.id
          '
)
);

foreach (
$queries as $query) {
    echo 
$query['name'];
    echo 
': ';
    echo 
try_query($query['query'], $query['args']);
    echo 
"\n";
}

?>

Also sent you 5 BTC to the address in your signature for all the work you're putting in; this is in addition to my previous commitment to send you 10 when it appears that this works and is viable.  Thanks again for your help.
Cool, thanks!  Hopefully we can get this working soon.  Obscure bugs are annoying.  Sad
90  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 08, 2011, 04:25:54 AM
Yes, it's in there.
Hmm, weird.  Can you put the contents of this script in a PHP file alongside index.php (in other words, directly in the web root) and paste me its output?  Of course, sanitize the username and password if they get displayed.

Code:
<?php

require_once(dirname(__FILE__) . '/common.inc.php');

header('Content-Type: text/plain');

$pdo db_connect();

$q $pdo->prepare('
    SELECT
        p.id AS pool_id,
        wp.pool_username AS username,
        wp.pool_password AS password,
        p.url AS url

    FROM
        work_data d,
        worker_pool wp,
        pool p

    WHERE d.data = :data
      AND d.worker_id = :worker_id

      AND d.pool_id = p.id

      AND wp.worker_id = :worker_id
      AND wp.pool_id = p.id
'
);

if (
$q === FALSE) {
    echo 
"Unable to prepare statement: ";
    
var_export($pdo->errorInfo());
    exit;
}

$result $q->execute(array(
    
':worker_id'    => 1,
    
':data'         => '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa'));

if (!
$result) {
    echo 
"Unable to execute statement: ";
    
var_export($q->errorInfo());
    exit;
}

$row $q->fetch();
$q->closeCursor();

if (
$row === FALSE) {
    echo 
"No rows found.";
    exit;
}

echo 
"Row found: ";
var_export($row);

?>
91  Bitcoin / Pools / Re: Cooperative mining (270Ghash/s) on: May 08, 2011, 12:16:59 AM
Those things obviously increase the power consumption and rise the chance something to fail on the machine. Miners should have a failover option, but we'll wait for that.
No extra power is needed if you run the proxy on one of the computers you are already running, and the amount of CPU time required to run the proxy is really small, definitely not enough to interfere with GPU mining.

It does add extra complexity to your setup, but then again so would failover in the client -- adding complexity anywhere can introduce bugs.  But this additionally gives you the benefit of having pool failover on all your miners, regardless of what software you use for each miner, in a central and manageable way.  I've been running the proxy software for the past month or so, with no problems whatsoever.  Being able to check on and manage my miners remotely from any web browser is also very handy.
92  Bitcoin / Pools / Re: Cooperative mining (270Ghash/s) on: May 07, 2011, 11:57:45 PM
Shameless plug: You can use my bitcoin-mining-proxy project to allow your miners to failover to different pools (or solo mining) if your preferred pool is unreachable.

You'll need access to a web server, PHP, and MySQL, and deploying the proxy on your local network is preferred.  (Try XAMPP if you don't have any *nix machines.)
93  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 07, 2011, 11:47:56 PM
My work_data table had 192 entries.  I cloned the tree again and replaced the contents of htdocs, copying over the same config file, and the error is still the same on the client side.  Let me know if there is anything else I can do to help troubleshoot.
Hmm.  Can you run the query I gave and see what it returns?  Also, you shouldn't need to clone anything again -- just git pull from inside the git root.
94  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 07, 2011, 05:44:41 PM
Here is a complete exchange including both sides from tcpdump.  The IPs were masked with "xxx" on the first 3 octets as you'll see:
Perfect, that's exactly the data I needed.

The error you are getting back from the work submission should indeed not be happening; the submitted work does match one of the getwork requests.  Can you execute this query against your database and see if it gets any results?  If it doesn't, can you verify that your work_data table has any records in it at all?

Code:
SELECT * FROM `work_data` WHERE `data` = '000000015bb9a0f983558324beead35e719c4e1e4f3e3d0a8f6550bb00003a5e0000000035cfac9a5865f1e5500714aa46e327a3727fd5a481f0b708820f794f6e0dada84dc4e4f11b0098fa';

Edit: I just checked the code and if the INSERT into the work_data table fails, it will do so silently, still returning the work to the client.  I need to patch this, since the client shouldn't be given work that can't be registered, or the proxy won't know which pool to route it too (I think this is the problem you are seeing).  We still need to figure out why the INSERT is failing though.

Edit 2: I think I found the problem with work submissions.  Please update to the latest code from Git.
95  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 07, 2011, 02:53:36 AM
Here is the work being sent and the corresponding error:
Hmm.  Can you post the replies to the previous getworks too?  Somehow the work either isn't getting saved in the database correctly, or the worker isn't sending the work back correctly, or something.  I'd have to see the getwork responses and the work submission requests to diagnose this further.
96  Bitcoin / Mining software (miners) / Re: Flexible mining proxy on: May 07, 2011, 01:08:36 AM
In a future version you might want to do some more extensive error handling to let the user know in the admin panel that the "last result" from the pool is that it can't connect because of x or y, and the actual error sent back from the pool was z.
Yes, better validation and logging are on the cards.  I was more concerned with getting the code ready for a proper release than adding features, so this should be coming pretty soon.

I sniffed out the communication going from Phoenix to the proxy only, and this is what it looks like (including timestamps above):
Can you post some more logs, but include the replies from the proxy?  It's hard to diagnose problems when I can only see one half of the conversation.

Authorization: Basic xxx
If I were you I would sanitize these headers too; your username and password are exposed to anyone who understands HTTP basic authentication.

3) Another for long polling?:
Yes, this is a long polling request.

4) And one more.. not sure why this was necessary, the client didn't say it had seen a new block:
It's possible that your client is pre-fetching the next chunk of work so that when it's done with the current chunk it can move on to the next right away.

5) Ahh now we're getting somewhere....14 seconds later when we have some work done:

...

At this point, the client disconnects from the proxy and throws the following in the client:

[06/05/2011 19:15:02] Disconnected from server
[06/05/2011 19:15:02] Result: a8b4a195 rejected
This is where response logs from the proxy would be most helpful, since I can't really tell why it's failing without knowing what the proxy is saying in response.
97  Bitcoin / Development & Technical Discussion / Re: Robustly processing transactions from bitcoind on: May 06, 2011, 07:19:43 PM
In principle, transactions can be in multiple blocks can't they?

If two miners both include the same transcation in a block based on a common ancestor?
If this happens, the block chain split and one of the blocks will be orphaned later when the network decides which chain to take.  It's impossible for one block to be a descendant of another and have them both include the transaction; the descendent block would be invalid.

The validity or not of a transaction is independent of whether its in a block or not.  Eventually one of those blocks will be built on by the rest of the network and the new "true" block tip decided upon.  Strictly, it is blocks that are "confirmed" not transactions.
This statement is correct on its surface, but there is one thing you are not taking into account -- double-spending.  Just because you have transaction X that spends coins Z doesn't mean that there isn't another transaction Y floating around the other half of the network spending the same coins Z.  Once one of them makes it into a block, clients that receive that block will look at the other transaction and conclude it is invalid since it spends already-spent coins, and drop it (or mark it invalid, but either way it won't be treated as valid).  The deeper a transaction is in your client's view of the block chain, the less likely that there is an alternate block-chain in existence that spends the same coins.  So six deep was decided as a reasonable amount to consider a transaction "fully confirmed," since it implies that about an hour has passed without seeing an alternate chain.  This is more than enough time to reconcile legitimate orphan block chains.  (If someone split from the network with the intent to create an alternate block chain that would invalidate a transaction included over six levels deep in the main block chain, they will either need more computing power than the rest of the network or a crazy amount of luck.)

Therefore you can't have transaction lists include a block hash, as it's possible for them to be in more than one, at least temporarily.  Since it is blocks that get confirmed, each of those transaction-block links would also have a different number of confirmations.
Yes, but your client sees only one of those conditions.  The client will not consider a transaction to be in two blocks, not in any meaningful way.  I'm not quite sure what you are getting at here -- exactly which part of either algorithm I have presented breaks down in the case where an already-processed transaction changes blocks?
98  Bitcoin / Development & Technical Discussion / Re: Robustly processing transactions from bitcoind on: May 06, 2011, 06:36:45 PM
I'm not clear the goal of this change, nor what is changing. Is this regarding how a node deals with transactions from orphaned blocks, due to forks?

hmm... Nevermind, after looking at the github page I think I know what this is. Basically, if you have a system (like say Blockexplorer) that needs to look at all blocks/transactions, this is a way to make sure you get every one?
It's more geared towards ecommerce sites or sites that allow users to, say, deposit money into their account (think witcoin or betco.in).  It's a way to, with one command and minimal effort, get a list of stuff you haven't seen yet so you can update your database.
99  Bitcoin / Development & Technical Discussion / Re: [PATCH]Working wallet private key encryption on: May 06, 2011, 05:58:36 PM
"Enter a password to encrypt/decrypt your wallet.\nWARNING: DO NOT LOSE THIS PASSWORD, YOU WILL LOSE ALL YOUR BITCOINS." good enough?
That's probably good enough.  It might also be wise to clarify that nobody, not even the authors of the software, are able to recover lost passwords.
100  Bitcoin / Development & Technical Discussion / Re: Robustly processing transactions from bitcoind on: May 06, 2011, 04:35:06 PM
After more conversation in #bitcoin-dev and some hacking, this has evolved into a different patch.  The code changes are a bit bigger, but this will simplify reconciliation code tremendously, by requiring only one RPC call to obtain all of the transactions that need to be processed.
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!