[BUG] - reward account balance can exceed maxLovelaceSupply genesis setting value

[bergr01]

Using latest master for both cardano-node and cardano-cli as of 15th of June 2020 on a private network (pHTN, guild operators).

Network's genesis config file has: "maxLovelaceSupply": 1e+14 (see https://github.com/cardano-community/guild-operators/blob/master/files/ptn0/files/genesis.json for the rest of the settings)

However, we have at least a couple of pools that generated more than that amount in rewards (somehow):

cli query stake-address-info --address 5821e0a24ace606b18e0cf73906ca9f5e447770ee7313c85b764f372bc33b4c1096778 --testnet-magic 4007 { "5821e0a24ace606b18e0cf73906ca9f5e447770ee7313c85b764f372bc33b4c1096778": { "delegation": "256660d4d5fa88b9895712f97c9607a4073b3325b441860c4777c9495db68037", "rewardAccountBalance": 128798458828899260 } }

I would have thought maxLovelaceSupply should be respected by whatever reward-related logic generated such ridiculous amounts? Currently I'm unable to withdraw these rewards to base address either, presumably because some UTXO-related validation is barfing with such a large value?

[rcmorano]

Some extra info: cardano-node commit used by one of those stakepools is 478230.

[dcoutts]

A dump of the ledger state via cardano-cli shelley query ledger-state would be handy. This may be large, so probably best to compress it and post it somewhere.

[rcmorano]

Just 32K for this testnet, find it attached here [0] :)

[0] ledger-state.json.log

[kevinhammond]

Thanks. We will investigate this.

[kevinhammond]

More context from @rdirt

Background: Essentially the issue surfaced because genesis since addition of minPoolCost - commits beyond 1.3.0-rewards - did not allow us a value for blockchain constant rho (monetary expansion) lower than 0.005, which meant our rewards for initial pools were pretty high.

We were however expecting rewards to be limited by max supply, but were a bit bamboozled to see that it kept increasing beyond max supply - which is the pressing issue.

I see @rcmonaro has already sent the ledger state to the issue. Happy to add any details required.

Also, anyone can connect to that chain using config/genesis here: https://github.com/cardano-community/guild-operators/tree/master/files/ptn0/files

[rdlrt]

lower than 0.005

Sorry - I missed a 0 while sharing with kevin, we were not able to set rho lower than 0.0005 , resulting in exponential rewards - exposing the issue

[JaredCorduan]

with the update from @mrBliss above, we will be able to view the amount of lovelace in the reserves using cardano-cli shelley query ledger-state (once the changes are in the CLI). the behavior in this issue is consistent with the reserves being larger than we expect (ie not starting out as maxLovelaceSupply - sum initialFunds.

[bergr01]

with the update from @mrBliss above, we will be able to view the amount of lovelace in the reserves using cardano-cli shelley query ledger-state (once the changes are in the CLI). the behavior in this issue is consistent with the reserves being larger than we expect (ie not starting out as maxLovelaceSupply - sum initialFunds.

grep -i -C 50 reser ledger.out { "_utxoState": { "_utxo": {}, "_ppups": {}, "_fees": 0, "_deposited": 900017000 }, "_delegationState": { "_dstate": { "_irwd": { "iRTreasury": [], "iRReserves": [] },

Does this help clarify the picture?

[JaredCorduan]

unfortunately not, @bergr01 , but thank you for trying. I really need to see where all the lovelace actually is in the system, especially the reserves. I know iRReserves looks like it might be the reserves, but it's actually a pending queue of potential reward account to draw from reserves funds (this is the mechanism for bringing the ITN rewards onto mainnet).

[JaredCorduan]

would y'all be willing to try to recreate this issue using the 1.15.0 tag? the logs from cardano-cli shelley query ledger-state will now give us some very helpful new information.

[kevinhammond]

We have been unable to reproduce this issue. It may be related to some specific configuration settings? I am closing it for now.