When I made the 48 share bounty for the new client, I didn't know there were so many differences between the 0.3 codebase and the 0.8 codebase. Now I see that there's many things to do do, so I suggest boosting the bounty from 48 shares to 96 shares. The 48 shares have already been sent, so this would be a boost of 48 share in round 33. Any objections, or should something be changed?
No objection but further reasoning is as follows:
I tried to keep it consistent but there were manual merges that were code reviewed and passed people's judgements but the code is complicated because its not "that" well designed so its hard to spot problems in the large scope of things by simply looking at the code and considering all options. I think I may have ideas why Hunterbunter is not able to connect and its simply a connection issue and doesn't make sense because its not even getting to the submit work state so its not even testing merged-mining other than setting it up so workers can start getting work... im not sure why its calling CreateNewBlock right on connect, whcih is called from rpcmining, but its something that I will figure out and know the answer soon (just that it takes longer than it should)
As far as the rpcmining, nothing was changed between 0.8.5 and devcoin, but there are probably many changes in the underlying structure because the base changed drastically... I don't see why it would be a problem with new client to new client interaction but to keep backwards compatibility with merged-mining in mind is a tougher task, and its hard to debug. If someone was familiar with the code they could help by getting the unit tests up and going, so we can actually run tests against the code without running it live. It would speed up development and I just didn't get around to it. Instead of doing that I think I'm good at finding issues in code by simple problem solving which is what I'll do in this case. It may be a small fix that will resolve the client issues and we will be fine after that, since syncing and sending/recieving doesn't seem to have any issues between client versions. Even the android client is happy now. But I do think if we want to roll forward it makes sense to keep up-to-date with bitcoin source and doing that means we wouldn't have to reimplement devcoin manually from a rebase everytime... that simply means we start fresh from 0.8.6 and add in devcoin again and not worry about backwards compatibility. We only have 1 major pool to consider and this new one, so its just a matter of setting a date/time in the future and saying we are moving to a new codebase...
If bitcoin has found to have a major flaw, then so does ours.. .we should leverage the development effort of bitcoin and not try to redevelop the wheel so its a more efficient path to achieve the same thing.
If we do follow this path, this would mean we follow bitcoins difficulty retargeting and all other specs, except the main devcoin differences like auxpow/reciever share system, to keep consistent and be able to reuse the tools of bitcoin, by adding in merged-mining capability similar to what I did with the android wallet... however the wallet took longer because of the difficulty algorithm which the code didn't have in mind to check previous set of blocks to average. Small things like this add up and will cause problems one day.
BTW for piece of mind I did merge in the version 1 block stuff in AcceptBlock already:
// Devcoin currently doesn't enforce 2 blocks, since merged mining
// produces v1 blocks and normal mining should produce v2 blocks.
#if 0
// Reject block.nVersion=1 blocks when 95% (75% on testnet) of the network has upgraded:
if ((nVersion&0xff) < 2)
{
if ((!fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 950, 1000)) ||
(fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 75, 100)))
{
return state.Invalid(error("AcceptBlock() : rejected nVersion=1 block"));
}
}
// Enforce block.nVersion=2 rule that the coinbase starts with serialized block height
if ((nVersion&0xff) >= 2)
{
// if 750 of the last 1,000 blocks are version 2 or greater (51/100 if testnet):
if ((!fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 750, 1000)) ||
(fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 51, 100)))
{
CScript expect = CScript() << nHeight;
if (vtx[0].vin[0].scriptSig.size() < expect.size() ||
!std::equal(expect.begin(), expect.end(), vtx[0].vin[0].scriptSig.begin()))
return state.DoS(100, error("AcceptBlock() : block height mismatch in coinbase"));
}
}
#endif
