Furthermore, if you compare the delegates those two transactions are voting for you can see that they are identical. So shouldn't their sum, approximately 137m BTS, be reported as a single slate in the stats somewhere?
IIRC, I had discussion on this issue with Vikram a while back about the slates, and we don't have uniqueness checking for slates currently.
Does that mean if two transactions are voting for the exact same set of delegates they could end up with different slate IDs? If true, does that mean toast's script is only looking at unique slate IDs rather than unique sets of delegates? But even if that was true, that still wouldn't explain the discrepancy between the stats toast posted and the transactions I talked about. Either there would have to be 137m BTS stake with a "unique slate" (whatever that means) in the stats OR there would have to be a 62m BTS stake with a "unique slate" and another 75m BTS stake with a "unique slate" in the stats. But the stats clearly show no 137m BTS stake "unique slate" nor does it show a 62m BTS stake "unique slate".
The other possibility is that those balances were grouped together after toast ran his script, but considering those transactions were made on Jan 28 (less than a day after toast's original post), I highly doubt it.
Ah, I think I found the bug with toast's script that explains the discrepancy I quoted above.
https://github.com/BitShares/bitshares/commit/8a19a15c1880f8f3251acb8c8fc081b2430a4634I'm pretty sure this part of the code
const auto scan_balance = [&]( const balance_record& rec )
{
auto id = rec.condition.slate_id;
if( slates.find(id) != slates.end() )
slates[id] = rec.balance;
else
slates[id] += rec.balance;
};
should instead be
const auto scan_balance = [&]( const balance_record& rec )
{
auto id = rec.condition.slate_id;
if( slates.find(id) == slates.end() )
slates[id] = rec.balance;
else
slates[id] += rec.balance;
};
or even simplified down to just
const auto scan_balance = [&]( const balance_record& rec )
{
auto id = rec.condition.slate_id;
slates[id] += rec.balance;
};
but I don't know if I like this because it isn't very explicit about what's going on.
The if statement with the != actually checks if the slate id already exists in the map slates and if it does it then replaces the existing value, else it adds to a non-existent value (which causes it to create a new entry in the map with a default value of share_type() == int64_t() == 0 and then adds rec.balance to it). This is the opposite of the desired behavior, and it leads to ignoring all balances with the same slate id except for the last one returned by the unordered iterator, which would be consistent with discrepancy I described in this thread.
By the way, I believe the same reversal bug exists with stats_unique_account_registrars() (
https://github.com/BitShares/bitshares/commit/a388e05e35bdc5b737a4f8d63eba3ed06dfba4fa). But I'm not really sure what is going with that function and why it is supposed to give any meaningful result.
Also, I should warn that this is based on me just reading the code and interpreting what it should be doing. I was too lazy to actually bother correcting the mistake and seeing if it fixes the discrepancy.