Bitcoin Forum
December 09, 2016, 02:11:34 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 »  All
  Print  
Author Topic: [Pushpool Web Frontend] Simplecoin v5.0 Opensource PHP/MySQL - NEW RELEASE  (Read 54924 times)
Wayno
Member
**
Offline Offline

Activity: 61


View Profile
June 19, 2011, 12:40:21 PM
 #61

requiredFunctions.php u need to have my copy theres a fucntion in there called lock

line 163

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
1481249494
Hero Member
*
Offline Offline

Posts: 1481249494

View Profile Personal Message (Offline)

Ignore
1481249494
Reply with quote  #2

1481249494
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481249494
Hero Member
*
Offline Offline

Posts: 1481249494

View Profile Personal Message (Offline)

Ignore
1481249494
Reply with quote  #2

1481249494
Report to moderator
1481249494
Hero Member
*
Offline Offline

Posts: 1481249494

View Profile Personal Message (Offline)

Ignore
1481249494
Reply with quote  #2

1481249494
Report to moderator
1481249494
Hero Member
*
Offline Offline

Posts: 1481249494

View Profile Personal Message (Offline)

Ignore
1481249494
Reply with quote  #2

1481249494
Report to moderator
dcconsulting
Jr. Member
*
Offline Offline

Activity: 41


View Profile
June 19, 2011, 01:03:06 PM
 #62

Ah thanks

Now I am getting this error,

Output from command php /var/www/cronjobs/cronjob.php ..

PHP Notice:  Trying to get property of non-object in /var/www/cronjobs/cronjob.php on line 157
XML-RPC: xmlrpcmsg::parseResponseHeaders: HTTP error, got response: HTTP/1.1 500 Internal Server Error
PHP Fatal error:  Uncaught BitcoinClientException:
  • : Didn't receive 200 OK from remote server. (HTTP/1.1 500 Internal Server Error)

  thrown in  on line 0


Probably because I have not solved any block yet.

ZA Bitcoin Mining Pool - JOIN US !!  www.zabitcoin.co.za  0% FEE !
South Africa's own mining pool Smiley
dcconsulting
Jr. Member
*
Offline Offline

Activity: 41


View Profile
June 19, 2011, 01:04:04 PM
 #63

By the way Excellent work, the site just seems to be smoother.

ZA Bitcoin Mining Pool - JOIN US !!  www.zabitcoin.co.za  0% FEE !
South Africa's own mining pool Smiley
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 20, 2011, 04:41:04 PM
 #64

Nice, a fork!

I haven't been able to do much lately, but it looks like I'll probably get around to getting v2 up and running this week.

I'll definitely take a look at Wayno's code too, to see if it makes sense to bring anything over

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
BurningToad
Full Member
***
Offline Offline

Activity: 207


View Profile
June 20, 2011, 11:32:34 PM
 #65

i have uploaded the db and new code.

Thanks Wayno!

Wayno
Member
**
Offline Offline

Activity: 61


View Profile
June 21, 2011, 04:10:07 AM
 #66

Updated db and code base, lotsa fixs and stuff.

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
froggy
Full Member
***
Offline Offline

Activity: 127


View Profile WWW
June 21, 2011, 12:34:17 PM
 #67

drrconsulting, regarding ozcoin's cronjob.php error, ozcoin seems to be using an amended version of bitcoin.inc.php  .  I was getting similar errors but replaced ozcoin's /includes/bitcoinController/bitcoin.inc.php with the bitcoin.inc.php from Xenland's current code and no more cronjob.php errors.

The /cronjobs/shares.php seems to hve an error.  I'm getting
Code:
PHP Warning:  implode(): Invalid arguments passed in [PATH-TO]/cronjobs/shares.php on line 69

Bit confused as to what's going on with 'id' in that script.
Wayno
Member
**
Offline Offline

Activity: 61


View Profile
June 21, 2011, 04:23:18 PM
 #68

oh yeah i forgot i changed the standard port 8332 to 8335

better change that in bitcoin.inc.php

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
frizzl
Newbie
*
Offline Offline

Activity: 28


View Profile
June 22, 2011, 06:46:00 AM
 #69

My stats seems off a bit,can any tell me what the "settings" table is used for ..its currently blank and I see it referenced quite a bit in the php code.  Do I need to add something?  So far everything else is working good but i have no server stats and some workers show wrong.  Cron jobs are setup and run fine, what times is anyone using?  Good job everyone btw.

1NtLm3jrRK2keDBMiBbTUvNetrkNuBV8hY
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 22, 2011, 07:20:18 PM
 #70

My stats seems off a bit,can any tell me what the "settings" table is used for ..its currently blank and I see it referenced quite a bit in the php code.  Do I need to add something?  So far everything else is working good but i have no server stats and some workers show wrong.  Cron jobs are setup and run fine, what times is anyone using?  Good job everyone btw.

yes, there is an insert line in the setup sql (try running just that line).

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
frizzl
Newbie
*
Offline Offline

Activity: 28


View Profile
June 23, 2011, 01:29:30 PM
 #71

Wayno i cannot get it to report online miners corretly.  I added the above fix from simplexoin and that claered up a bunch of the stat issues but still have miners online reporting incorrect.  Can u upload ur settings db config?  All time stats are not quite working right either it seems.  I am mining w 3 miners currentlyw2 different test accounts.  Thanks

1NtLm3jrRK2keDBMiBbTUvNetrkNuBV8hY
Wayno
Member
**
Offline Offline

Activity: 61


View Profile
June 24, 2011, 05:25:39 AM
 #72

go into admin panel and change cheating to proportional as i haven't removed it.

when u upload the database it will be cleaned u need to add all the settings in.

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
frizzl
Newbie
*
Offline Offline

Activity: 28


View Profile
June 24, 2011, 08:14:33 PM
 #73

Wayno, what rows are included in settings same as in original simplecoin i have:

currenthashrate    
currentroundshares    
currentworkers    
mtgoxlast    
pagetitle
sitebalance    
sitepayoutaddress    
sitepercent    
siterewardtype    
slogan    
statstime    
websitename

thanks for all ur help

1NtLm3jrRK2keDBMiBbTUvNetrkNuBV8hY
Wayno
Member
**
Offline Offline

Activity: 61


View Profile
June 25, 2011, 02:46:14 AM
 #74

currenthashrate    43379
currentroundshares    1215632
currentworkers    124
mtgoxlast    1
pagetitle    Ozco.in
sitebalance    0
sitepayoutaddress    1GG9HQZchCRxPSBV5SwZ9GoYEVq9vVLGqU
sitepercent    1
siterewardtype    1
slogan    Making Bitcoins Simple
statstime    1308969381
websitename    Ozco.in

thats wat it currently looks like

statstime    1308969381 is the only one i added

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
frizzl
Newbie
*
Offline Offline

Activity: 28


View Profile
June 25, 2011, 03:00:28 AM
 #75

Ok thanks for verifying, i found statstime in the code making sure there wasn't any others.  Thanks for your help

1NtLm3jrRK2keDBMiBbTUvNetrkNuBV8hY
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 25, 2011, 06:58:00 AM
 #76

Version 2 beta is available from github!

There are several sql changes and you will need to manually enter them if you choose to upgrade an existing install.
Note: counted in shares history is now an enum.
To convert update existing- UPDATE shares_history set counted='1' where counted=1; update shares_history set counted='0' where counted=0
ONLY RUN if your shares_history counted is not an enum after updating tables

There could be stats errors, and some unchanged terminology that needs updating. That said, payouts & balance figures should be correct!

Please note any issues you have (or an update sql script if you have the time!!! I hate writing those by hand).

Thanks, and more features coming Smiley

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
froggy
Full Member
***
Offline Offline

Activity: 127


View Profile WWW
June 25, 2011, 05:53:41 PM
 #77

Yayy!  Thanks Simplecoin - trying it now.

A tip for testing....
Code:
I was getting errors when testing the crobjobs via command line ssh:
[code]
 PHP Notice:  Undefined index: REMOTE_ADDR

so I've password protected the cronjobs folder using htacess.

You should then be able to safely change the code in the cronjobs from :
Code:

//Check that script is run locally
$ip = $_SERVER['REMOTE_ADDR'];
if ($ip != "127.0.0.1") {
echo "cronjobs can only be run locally.";
exit;
}

to
Code:

if (isset( $_SERVER['REMOTE_ADDR']))
 {
$ip = $_SERVER['REMOTE_ADDR'];
if ($ip != "127.0.0.1")
      {
echo "cronjobs can only be run locally.";
exit;
      }
  }

...which will enable you to test the cronjobs via the command line.[/code]
simplecoin
Sr. Member
****
Offline Offline

Activity: 406



View Profile WWW
June 25, 2011, 10:54:50 PM
 #78

Yayy!  Thanks Simplecoin - trying it now.

A tip for testing....
Code:
I was getting errors when testing the crobjobs via command line ssh:
[code]
 PHP Notice:  Undefined index: REMOTE_ADDR

so I've password protected the cronjobs folder using htacess.

You should then be able to safely change the code in the cronjobs from :
Code:

//Check that script is run locally
$ip = $_SERVER['REMOTE_ADDR'];
if ($ip != "127.0.0.1") {
echo "cronjobs can only be run locally.";
exit;
}

to
Code:

if (isset( $_SERVER['REMOTE_ADDR']))
 {
$ip = $_SERVER['REMOTE_ADDR'];
if ($ip != "127.0.0.1")
      {
echo "cronjobs can only be run locally.";
exit;
      }
  }

...which will enable you to test the cronjobs via the command line.[/code]

Thanks, I didn't have any problems running wget http://localhost/cronjobs/...., but I'm happy to implement that. Seems like a harmless addition.

Donations: 1VjGJHPtLodwCFBDWsHJMdEhqRcRKdBQk
AnnihilaT
Full Member
***
Offline Offline

Activity: 196



View Profile
June 26, 2011, 09:22:21 AM
 #79

Hi Mike,

I've been hacking on your code a bit for the last day again and testing everything on a private testnet in a box setup with 2 nodes and there are some things puzzling me about how the cronjob.php code works.  Mainly in the logic.  Ill try and explain each on separately.

Checking if we found a block.
Here we query bitcoind with a listtransactions query with no extra arguments so we get a default count of the last 10 transactions.  We check if the category is "generate" and if so we assume we may have found a block and start doing some logic to make sure of that.  

This is where i already dont get it.   On my testnet setup,  when we find a new block its category is immature and remains that way until it receives 120 confirmations at which point it changes from "immature" to "generate".  see below:

Code:
   {
        "account" : "",
        "category" : "generate",
        "amount" : 50.00000000,
        "confirmations" : 120,
        "txid" : "47a833ba9e311a839988136a283d9e6a8d05f7c609cc5ec26de397f352472751",
        "time" : 1300079031
    },
    {
        "account" : "",
        "category" : "immature",
        "amount" : 50.00000000,
        "confirmations" : 119,
        "txid" : "c31c89383ec77234cc2c2cbeca87edbc2b6348edba9d0e6c343fc34f1ed730ff",
        "time" : 1300079115
    },

This means that by the time we have a transaction with the "generate" category it will have long ago fallen out of the data returned by the listtransactions query since that only shows the last 10 transactions.  I realize that works a bit different on an active live network but it still seems odd to me that at least the way im reading the code that you rely on the assumption that we wont find more than 10 blocks out of 120 (or something like this - maybe i made a math error).  If i leave it set like this on a private testnet the side effect is that no blocks are ever seen as found and the round never ends because by the time the block has changed from immature to generate it has fallen out of the list of the last 10 transactions because our pool is finding every single block.   Does this make sense?  

Updateing confirms
The next part also confuses me for a similar reason.  NExt we go through all the transactions and update their confirms.  Here again we check the category if its set to "receive" but from what i can see an immature or generated block will never have this category.  Its category is always either generate or immature (on testnet).  see below:

here is a closer look at a txid which has matured
Code:
# bitcoind -datadir=testnet/1 gettransaction 47a833ba9e311a839988136a283d9e6a8d05f7c609cc5ec26de397f352472751

{
    "amount" : 50.00000000,
    "confirmations" : 120,
    "txid" : "47a833ba9e311a839988136a283d9e6a8d05f7c609cc5ec26de397f352472751",
    "time" : 1300079031,
    "details" : [
        {
            "account" : "",
            "category" : "generate",
            "amount" : 50.00000000
        }
    ]
}

and a closer look at one right after it with only 119 confirms and will be maturing next round:
Code:
# bitcoind -datadir=testnet/1 gettransaction c31c89383ec77234cc2c2cbeca87edbc2b6348edba9d0e6c343fc34f1ed730ff

{
    "amount" : 0.00000000,
    "confirmations" : 119,
    "txid" : "c31c89383ec77234cc2c2cbeca87edbc2b6348edba9d0e6c343fc34f1ed730ff",
    "time" : 1300079115,
    "details" : [
        {
            "account" : "",
            "category" : "immature",
            "amount" : 50.00000000
        }
    ]
}

so the effect here is that nothing will ever get its confirms updated unless your check is changed to immature or generate.   Can you explain to me the "receive" category and why you are using this as a check?  

Calculating payouts and ending the round
This part seems to be pretty straightforward assuming that the previous 2 steps went right with the exception that it looks like in this part of the code is where we close out the round (am i wrong here).   It seems that the round doesnt get closed out properly if this part of the code doesnt run (for example because there are not yet enough confirms on any of the blocks.)   Is it true that this is where the round ends or at least some part of the logic for ending a round is in here?  Or is that completely all up top of the code where we move all old shares to shares_history.  

Other random questions
Wouldnt it be better to track 2 balance amounts - an unconfirmed and a confirmed amount and only allow payout of course on the confirmed balance?  It seems the way the code is written now that a user will have no idea they might have earned until all found blocks have at least 120 confirms.   So if you are just starting up a new pool, your new users will show a 0 balance until at least 120 or so blocks have been found on the network which would confuse them and maybe scare them off right from the start as it would look like they arent earning anything.   Am i correct about it working like this?  

I hope im explaining this well enough for you to get my point.  It;s late and i know i might not be making myself very clear.   Thanks for any clarification you can give!! Maybe im missing something very simple here. Smiley
drontus
Jr. Member
*
Offline Offline

Activity: 42



View Profile
June 26, 2011, 09:51:45 AM
 #80

workers wan't connect to pool =\ help plz
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 »  All
  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!