Weird rounding function

[tomasbrod]

DPoR reward is affected by this very weird function. Discovered by am2on on IRC. It makes reward amount always end with decimals "0124".

So I noticed something interesting -- every single time I get a DPOR reward, it always ends in "0124". > Look: https://i.imgur.com/JjsrtCp.png

Relevant code main.cpp:2053

std::string sTotalSubsidy = RoundToString(CoinToDouble(nTotalSubsidy)+.00000123,8);
if (sTotalSubsidy.length() > 7)
{
      sTotalSubsidy = sTotalSubsidy.substr(0,sTotalSubsidy.length()-4) + "0124";
      nTotalSubsidy = cdbl(sTotalSubsidy,8)*COIN;
}

[iFoggz]

Good find!

the length of TotalSubsidy is always more then 7 in length. Am I reading that correct? Rounds to 8 decimal places and adds 0.00000123 to maintain 8 decimal places in case it rounds to less then 8 decimal places? if the length is greater the 7 (which is always) it removes last 4 of the length and add "1024"

X.XXXXXXXX -> X.XXXX0124
XX.XXXXXXXX -> XX.XXXX0124
XXX.XXXXXXXX -> XXX.XXXX0124
XXXX.XXXXXXXX -> XXXX.XXXX0124

I don't see why you would round it up just to have the if statement be true to remove last 4 to add "0124" I understand that if the ending decimal place no matter where in the string is a 0 it is not kept and could understand a +0.00000001 if the length is less then 10 making sure you always have least 0.00000001 to maintain 8 decimal places.

seems like a patch job gone somewhere beyond?

[denravonska]

It seems to be used to determine if a transaction is interest or PoR, rpcwallet.cpp:

bool IsPoR2(double amt)
{
    std::string sAmt = RoundToString(amt,8);
    if (sAmt.length() > 8)
    {
        std::string suffix = sAmt.substr(sAmt.length()-4,4);
        if (suffix == "0124" || suffix=="0123")
        {
            return true;
        }
    }
    return false;
}

... snip
std::string type = IsPoR2(CoinToDouble(r.amount)) ? "POR" : "Interest";
{
    entry.push_back(Pair("Type", type));
}

Surely there must be a more straight forward way of doing that?

[iFoggz]

interesting way to do it but makes sense. Might be another way better but My guess is because there is no proof-of-research flags in the transactions this is a easy way for them to be identified i guess. the transactions it checks least from me coping the transaction ids in transaction history just shows inputs/outputs but nothing i can tell what is what really. And at end of it shows the mint as interest with type = interest.

[tomasbrod]

More research is needed. When I doubleclick por transaction, it shows me the id and stuff. But in getblock x true output, this por transaction is actually the second one and without hashboinc. The coinbase one with hashboinc is first and it has zero input and output.

[iFoggz]

@tomasbrod yea i noticed that as well. I was gonna original post saying use the hashbonic till i realized the second one didn't have that information. so that one went right out the door.

1. Would it be to much to pull the coinbase transaction as well with the one we are checking and see if the grc address in hashbonic ismine and then if so if Research subsidy field is 0.00? if it is not 0.00 it would be PoR and if it is 0.00 its interest block. the hashbonic has a fields for a grc address attached to wallet (this is never the same one i staked on). But the research subsidy field is always there even if your an investor.

2. Would it be to much to pull the block information verify if GRCaddress ismine and read the flags of the type of block? whether proof-of-research is included in the flags or not?

Something consistent in both researcher and investor is GRCaddress. and the research subsidy field in hashboinc.

Just some ideas. It would of defiantly been better if there was a flag in the transaction from the beginning of time which stated whether it was PoR or Interest.

[tomasbrod]

Keeping this open as a reminder for improvements to the transaction dialog.

[jamescowens]

PR to deal with this is merged. Closing.