Hi Mike, Maybe i didnt make it clear that im implementing these things also where i think they make sense so maybe we should talk about working together on the project? Also, i had alot of questions in there as well for you and wonder if you could maybe (if you have time) answer some of my questions and let me know if things are actually as i understand them to be or if im making some wrong assumptions. While i am testing the changes im making, i also want to be sure that im not making some false assumptions about how it all works. Particularly im interested to hear your thoughts about the whole cronjob logic because im planning on making some significant changes here and would be nice to hear another opinion from someone who has used the code live. I can only test on testnet. Can you verify that under normal operation with the code you run that indeed shares just keep counting up until the first block we found has 120 confirms and that maybe some other things work kind of weird as well until we hit the first block with 120 confirms? Perhaps with my changes ive intoduced some oddities and want to make sure that the problems im "fixing" arent self induced  Anni As far as working together, currently I want to personally check any code that comes through before it posts. That said, I tend to implement just about any pull request that is beneficial and benign. I'm currently going through the cronjob logic myself. It works currently since blocks aren't generated very often, but it needed a heavy overhaul. I'm changing the way it checks confirms & generations. The initial block now looks at generate and immature in the past 200 txs. The second block will look through networkblocks and not transactions. it will check bitcoind against txid to count confirms if less than 120 in networkblocks. After that is all said and done, I intend to fork bitcoin & pushpool into one codebase to cut down on getwork traffic and expose new rpc commands to filter transactions based on category. To answer your other questions: calculating payouts: yes this ends the round. by setting counted='1' the shares are now invalid for the current round. confirmed & unconfirmed balances: I think that would just add further confusion. Estimated balances alone have caused confusion that is a real pain. I'm tempted to even remove that from my own pool as it seems to anger people when they can't cashout a non-existent balance. |
|
|
|
i'm try to job in this pool but with all correct value in btcgui i read ever the same message "problem communicating with bitcoin RPC" why?
for username, are you using your worker username? username: username.1, password:x? |
|
|
|
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: {
"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 confirmsThe 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 # 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: # 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 roundThis 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 questionsWouldnt 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. Yes, that's on the agenda. The code was based around modifications to Xenlands original. After seeing it in action, I think there are better ways to implement it. Thanks for the input, I'll definitely put some weight to it. |
|
|
|
|
So far everything seems to be holding it's own. I'll be keeping watch, but it seems nice and stable. The new code is keeping server load low and seems to be much more responsive.
Fire up the miners, let's get some blocks solved!
|
|
|
|
Yayy! Thanks Simplecoin - trying it now. A tip for testing.... 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 :
//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
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. |
|
|
|
I'm honored to see my pool front-end being used by the Ars crowd Best of luck! |
|
|
|
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 tablesThere 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 |
|
|
|
yes, I've had some health problems and I didn't want to launch when I would not be available. I'm finishing up the v2 code now, and hope to have it implemented soon.
Hope you are feeling better, thanks for the update. Many thanks! It seems I'm on the road to recovery... just a few more procedures and I should be heading towards normal  That said..... the site is back online! Please use a backup-miner just in case there are any site issues. I'm running dupes for each machine myself. Stats are now updated every 30min (just haven't updated the notices... coming soon). Also, some lifetime stats might be off (no worries, current shares are still there and counted!) Additionally, I'm thinking of eventually moving to a small fee (there will be warning, and it will be on a new block) to encourage donated hashes for further development of the simplecoin front-end. Yes, it's true, I'm more motivated when money is involved. |
|
|
|
|
Just got guiminer runing on ubuntu 11.04 with fglrx!
I had to build the beta pyopencl to get it to see my cards, but it's running the phat-k poclbm mod and matching my hashkill results!
If it does better with timeouts, this is a big win.
|
|
|
|
Great. I still paid 272.27, not 220 as you're claiming....... Oh well, ebay it is. |
|
|
|
Picture of goods with handle name and date please, will you use clearcoin?
I'll get some pics up later. I will use clearcoin if I feel the buyer has adequate reputation. |
|
|
|
someone's angry  seriously, if someone wants to buy something for a set price, why are you so upset by it? |
|
|
|
Someone got mad. I paid a total $272.27 for these 2 cards. The identical ones I use in my headless miner get 266mhash. My 6870s get 270 (won't oc for crap), and I paid nearly $200 each for them. So, my 272 + 10-15 for shipping means I might make a few dollars on this item that's in high demand. It's cheaper than most ebay shipped, and I take BTC. It's definitely cheaper than anyone who's asked for $175-200 for these. Take it or leave it, I don't care. If no one bites I might just get a new mobo/psu and use them myself or sell them on ebay. |
|
|
|
Any updates on the relaunch?
yes, I've had some health problems and I didn't want to launch when I would not be available. I'm finishing up the v2 code now, and hope to have it implemented soon. |
|
|
|
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). |
|
|
|
I bought these to add to my mining rigs.... One rig doesn't have enough room, the backup I thought I could use doesn't have a strong enough psu, and the other is just too much heat to be next to me in my main rig. So, they are new but open box, I have everything including the box. $160 (or equivalent TH/gox (if it's up)) each shipped to continental US. heatware: tsd ebay: supreme_deals_tn I'll verify either |
|
|
|
|
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
|
|
|
|
|
so, signed up with a unique password....
1LZWxrxExKWRRDcZrwoQQ5mWSq9vHwysvL
will it payout? we'll see.
UPDATE: No, apparently not.
|
|
|
|
Why you need that ? For me poclbm eats less then 1% CPU.
Well, in my case, using stream 2.4 in windows 7 64bit, each opencl program will go full bore for a whole cpu WHILE GPU MINING if you let it. So, with my usual 4 miners open I get 4 cpus at 100% On my linux miner, hashkill uses 1-2% cpu, same with phoenix and poclbm. |
|
|
|
|
Show Posts
