Quote from: Hunterbunter on February 08, 2014, 03:20:48 AM

Quote from: sidhujag on February 08, 2014, 02:37:53 AM

Quote from: Unthinkingbit on February 08, 2014, 02:15:29 AM

Quote from: emfox on February 08, 2014, 01:13:13 AM

..
I'm not objecting but is it better if we have an hashpower criteria, e.g. if the pool hash reach 20g, then it's ok for the 24 shares bounty. So not every pool who has deploy the same code can apply this bounty.

The reason for the bounty is to see if Sidhujag's Daemon makes devcoin blocks that the old clients accept. We just need a single block for that. If it does, then we can make Sidhujag's the official client and archive the old one.

You really think its half the amount of work to test a pool than it is to develop the source? So does this mean he would have to dive into the source to figure out whats wrong if that os the case? Seems most of the hard work is in the code since that would be the problem and not the setup of a generic p2pool.

I agree with you, and I'll split the bounty with you if we can figure this out together, and the pool manages to get a raw devcoin block. Whatever amount you think is fair. It may not even be a problem with the source at all, and just a problem with my server, which another pool might not have. The server seemed to have been working fine up until I announced it yesterday, and then my isp replaced faulty ram and it died a horrible death in many ways. Everything got back up except devcoind, which didn't have a problem up until then. It's probably not a source problem, but I need source advice to try and identify a potential problem with my server. Either way, if you can help me fix it, everyone wins.

On a side note, I do also agree with emfox's suggestion that the devcoin wallet/daemon developers need to be well taken care of. Our whole network runs off it! One could easily spend 40 hours a week on something like the source and make it awesome + features.

Quote from: sidhujag on February 08, 2014, 02:41:58 AM

Seems it throws a fit when creating a block? Doesntthis get called when doenloading blocks from the chain? whats the difference. Is it the transaction stuff tht happens after checkblock is called?

Seems there is an issue in the creation of a new block... Hmm how would i debug this one?

Good thing is it is consistent.. so the p2ppool is sending the command right away amd I can put a bunch of console output statements to see what is going on.. I can add these to github ill tell you when to rebuild.

I'm not sure if it's when it tries to create a block, it looks like it's failing when it's trying to check the transactions. There might be something incompatible with what p2pool thinks its asking and what devcoind is expecting. Have you (or anyone else) made any changes to the transaction code after the fork?

What looks like is happening is the daemon starts up fine, gets the new blocks fine, and then as soon as p2pool throws what I linked above at it (merged getauxblock), it refuses connections until it terminates. We need to figure out what's causing this:

Code:

ERROR: CTransaction::CheckTransaction() : txout.nValue negative
ERROR: CheckBlock() : CheckTransaction failed

whenever p2pool tries to getauxblock on it.

I made fee changes that may have broke it.. maybe its a good idea to work backwards from the first stable release like 1.0.3 or whatenot looking at history.