Reset both Subnodes after Minting a block

[Stonygan]

What happened:

https://chainz.cryptoid.info/dfi/address.dws?8TyHf5WdQatKWmkSoZk8aK4Qftqjjrai3Z.htm This Masternode is not locked It seems after minting a block, both Subnodes reset to 1. Last block of this Node was 2021-08-20 23:42:11, block before over 9 days, but both Subnodes have TM 10.

What you expected to happen:

Only on Subnode reset to TM1.

How to reproduce it (as minimally and precisely as possible):

What are your environment parameters:

VPS with Version 1.8.0, correct Chain, correct blockheigt and Hash.

Anything else we need to know?:

[defichain-bot]

@Stonygan: Thanks for opening an issue, it is currently awaiting triage.

The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.

Details

I am a bot created to help the [DeFiCh](https://github.com/DeFiCh) developers manage community feedback and contributions. You can check out my [manifest file](https://github.com/DeFiCh/ain/blob/master/.github/governance.yml) to understand my behavior and what I can do. If you want to use this for your project, you can check out the [DeFiCh/oss-governance-bot](https://github.com/DeFiCh/oss-governance-bot) repository.

[uzyn]

Interesting. @Stonygan is it, by any chance, doing parallel mining? Not saying that it's an intended behavior, just for us to have some data while looking into this issue as most other masternodes are having their multiplier treated independently.

[uzyn]

/triage accepted

[Stonygan]

Its no parallel mining, only one VPS. User says it happens every time if the Operator found a block.

[prasannavl]

Thanks @Stonygan - can confirm that this is due to a bug in how pre-Eunos Paya masternodes are carried over.

Quick summary: Until both the subnodes have mined their first block after Eunos Paya, subnode 1 is using subnode 0's record as fallback, due to a bug. We're working on a fix to address this.

Meanwhile, however, once the first block is mined by both subnodes (which, while probabilistic is still likely to happen [1]), it should return to the expected state. (As of writing this note, we see around 5% of the overall masternodes affected by this, after 3 weeks).

-- [1] https://mydeficha.in/masternodes.php

[eudaldkp]

Hello @prasannavl , thanks a lot for your answer. I'm the guy that @Stonygan is helping. It has just minted another block, and both TMs got reset again. Is it possible that I am still being effected by this bug? It will be soon almost 4 weeks that the MN has been working basically at 50%. Also, is there some way to check which subnode minted the block?

Thank you.

[prasannavl]

Hi @eudaldkp. Thanks for reaching out, and appreciate your patience on this.

Is it possible that I am still being effected by this bug?

Yes. I believe what happened is that the same subnode has mined the other block again. This is purely probabilistic and unfortunately, seems the dice got rolled against the other subnode again.

Also, is there some way to check which subnode minted the block?

The subnodes are meant to be an internal implementation detail, with only the target multipliers exposed. So, I'm afriad there is no direct way to get these from the node (the difficult way being to parse through leveldb files manually). However, I don't believe doing this is needed, since we have already identified this line as the cause.

[eudaldkp]

Hello @prasannavl . Thanks for your answers. I guess I was just unlucky and it's just a matter of waiting. Is there a chance the bug gets fixed soon and I don't have to depend on probabilities? Also, I'm new to the whole masternode world and I don't want to come off as entitled or anything like that, but is compensation for stuff like this something that is considered? Due to this bug I've lost on ~370DFI, and I'm missing out on more everyday. I know DeFiChain is not a company or anything like that, but I wonder if there's a fund or something similar destined to these kind of things.

Thank you!

[uzyn]

Thanks for reporting this bug @eudaldkp @Stonygan . Unfortunately as this is part of blockchain and it's not discriminative, the blockchain is unable to refund. APY on blockchain is also not guaranteed.

The development team is still looking into ways to address this issue. It could either be fixed during the next upgrade – Fort Canning, or it could be fixed earlier if no consensus upgrades are needed.

For masternode owners, if you are affected by this bug, i.e. having a masternode that was created pre-Eunos Paya and your targetMultipliers for both subnodes reset at the same time upon found block, there are 2 things you can do:

1. Do nothing. There's a 50% chance that it will fix itself when the next block is found. If a block is found by the 0th subnode, the masternode will not be affected from then on.

2. If you do not want to wait for that, you can also resign and re-register a new masternode. A newly registered masternode will not have this issue.

Thanks. More updates from the development team.

[eudaldkp]

Thank you @uzyn for your answer. I understand. As for now, I do not want to go through the whole setting up a masternode process, so I will wait and see if it gets fixed in the next block. Fingers crossed! Anyway, is the fix for this bug coming out soon? I've seen that @prasannavl has added a workaround but I am not very familiar with github.

Thanks

[prasannavl]

@eudaldkp - good news; we are currently testing the fix and plan for an optional minor release soon. Very likely that it's in the coming week and that should move it past the bug condition deterministically, regardless of the probabilities.

Please keep an eye out for the next release. Hope that helps!

[eudaldkp]

Hello @prasannavl , thanks for working on it. Yesterday night the 4th block since Eunos was minted and it finally fixed the bug. Again, thank you @Stonygan and all the people involved, you guys helped me stay sane haha!