dooglus
commented
8 years ago It appears the first such instance of this happening was in block 17982:
old 17981: "digsupply" : 6157.49432438,
new 17981: "digsupply" : 6157.49432438,
old 17982: "digsupply" : 7599.00197100,
new 17982: "digsupply" : 7612.81833822,http://khashier.com/tx/f76339adf1d73901daf9ef8e66fa0a090093fc6b2f56b3fa1960cfb484f97317, mentioned in OP is in that block.
The client keeps track of "digsupply", but gets it wrong in the event that a single transaction digs up two 4.6 outputs that were created in the same transaction.
For example, 2abba6a64b0409fe064b5ca6be712e556e1096659a242b48e16a25db7b97831d outputs 86 and 161 were both first moved as f76339adf1d73901daf9ef8e66fa0a090093fc6b2f56b3fa1960cfb484f97317 inputs 41 and 42. The client only notices input 41, and not input 42.
The dig detection code in CTransaction::FetchInputs() needs to move from the 1st to the 2nd loop over the inputs, since the first loop is only making sure the transactions can be loaded, and skips any 2nd or later inputs from a single transaction.