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.
