BOUNTY - 1500 HUC (approx 2+ BTC) - Huntercoin Mining Bug

[snailbrain]

We are placing a bounty from the undecided bounty part of the pre-allocation --- we want to get this fixed sooner rather than later, so here is an opportunity for some coders to get some Hucs..

Problem - Miner getting stuck on blocks

Eligius Log:

http://pastebin.com/raw.php?i=fbAitJ1Q

Problem seems to be:

that there is some transaction that is currently in the memory pool of nodes that can be put into block and the block can be mined, but then won't be accepted. I.e. some discrepancy between CreateNewBlock and ProcessBlock.


we are looking through it, but it is time consuming - if someone spots it first before us, they can claim this bounty.

we are aware of the failing name_firstupdate bug when re-using name of killed player, who sent chat message in the last move.


Bounty = 1500 HUCs

p.s. no need to issue fix, just need the fault

show the place in source code. I.e. discrepancy between CreateNewBlock and ProcessBlock, or something like that

Check here first, to see if been solved: https://bitcointalk.org/index.php?topic=456182.0

[DavidT]

Could it have to do with size? maybe something related to line 470 in cryptlib.h? Sorry, didn't have a look at the source at all before, so might be totally off, but would possibly make sense if there is a size issue. Anyway, I keep on looking for a bit, fingers crossed you can pinpoint it soon, without a debug environment and on the weekend hard to say, geeez.

[DavidT]

gotta go, will maybe have a look later when I get time, good luck

[ahmed_bodi]

a debug log would help

[rsnel]

My guess:

Failure probably is in  CBlock::ConnectBlock() at line 1319.

nFees is initailized at 0, never changed and then vtx[0].getValueOut is checked against GetBlockValue(pindex->nHeight, nFees), since nFees == 0 this silently fails.

Edit:

Code:

keypool keep 882
InvalidChainFound: invalid block=7ee9a9e1ff1ffc925894  height=39735  work=216983967497595029143
InvalidChainFound:  current best=77c39192bb4a4a8a88f2  height=39734  work=216897912273401034588
ERROR: SetBestChain() : ConnectBlock failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: BitcoinMiner : ProcessBlock, block not accepted

As can be seen here: CBlock::SetBestChain() craps out at if(!ConnectBlock()) at line 1451. First visible error is from InvalidChainFound(), so ConnectBlock() fails silently (could also be txdb.Write(), but seems unlikely).

Edit2: mmmm, if nFees really doesn't get updated, why doesn't this function fail more often?

[snailbrain]

My guess:

Failure probably is in  CBlock::ConnectBlock() at line 1319.

nFees is initailized at 0, never changed and then vtx[0].getValueOut is checked against GetBlockValue(pindex->nHeight, nFees), since nFees == 0 this silently fails.

Edit:

Code:

keypool keep 882
InvalidChainFound: invalid block=7ee9a9e1ff1ffc925894  height=39735  work=216983967497595029143
InvalidChainFound:  current best=77c39192bb4a4a8a88f2  height=39734  work=216897912273401034588
ERROR: SetBestChain() : ConnectBlock failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: BitcoinMiner : ProcessBlock, block not accepted

As can be seen here: CBlock::SetBestChain() craps out at if(!ConnectBlock()) at line 1451. First visible error is from InvalidChainFound(), so ConnectBlock() fails silently (could also be txdb.Write(), but seems unlikely).

Edit2: mmmm, if nFees really doesn't get updated, why doesn't this function fail more often?

thanks for the response, much appreciated

seems not the issue, and could be the buggy tx is no longer in the memory pool - asking pools if they have had any issues since

nFees is updated properly and if there was such an bug, all blocks would fail as you pointed out

I've been running a dummy miner (with minimum difficulty for 10 hours) and the error never happened. Maybe the buggy tx stopped broadcasting and is not in the memory pool anymore.

Will be an update to fix name/death/chat bug -- Miners must upgrade last -- (have messaged pools)

Also I added more debug messages into ConnectBlock and related functions, hopefully it'll help to locate the problem.

[rsnel]

Indeed:

Code:

bool CTransaction::ConnectInputs(CTxDB& txdb, map<uint256, CTxIndex>& mapTestPool, CDiskTxPos posThisTx,
                                 CBlockIndex* pindexBlock, int64& nFees, bool fBlock, bool fMiner, int64 nMinFee)

nFees is passed as a reference, so it is updated  

Will look further, I suspect some edge case in the calculation of the fees. That would be why this error only occurs in a busy game and not in a test setup.

I still would place a debug output at line 1320, detailing vtx[0].getValueOut() and GetBlockValue()

[snailbrain]

Indeed:

Code:

bool CTransaction::ConnectInputs(CTxDB& txdb, map<uint256, CTxIndex>& mapTestPool, CDiskTxPos posThisTx,
                                 CBlockIndex* pindexBlock, int64& nFees, bool fBlock, bool fMiner, int64 nMinFee)

nFees is passed as a reference, so it is updated  

Will look further, I suspect some edge case in the calculation of the fees. That would be why this error only occurs in a busy game and not in a test setup.

I still would place a debug output at line 1320, detailing vtx[0].getValueOut() and GetBlockValue()

Great, could be closer to the truth - keep going <3

I had a similar guess and placed a debug output (line 1320), though I did not print values (just prints whether they are correct/wrong).

Will add a more detailed message