Closed DanielZirkel closed 1 year ago
@DanielZirkel: 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.
This specific error would relate to a pre-GrandCentralEpilogue client that is not aware of the additional mint tokens field.
ConnectBlock: ApplyCustomTx on 32c70141b4da3129d353c024d58f381257701a0a1c8a22901f151002dd952d12 failed with MintTokenTx: deserialization failed: excess 1 bytes
Data for this TX is...
446654784d017c000000009435770000000000
...which means...
DfTx Minttoken - one balance - token 124 - amount 20 - empty to field
...it is the empty to field that pre-GrandCentralEpilogue clients will fail on.
A staking node could have failed to update in time and created a fork that some people are now ending up on.
Today another person had the same problem and it looks like he is not alone on this chain:
~/.defi/defi-cli getactivemasternodecount 2000
1243
Closing this, and it's no longer relevant and was caused by incorrect networks. Please reopen if these issues are being faced again.
What happened:
I had some issues synchronizing my node. With the help of Kügi we realized that my node was on a wrong chain. Here you see the blocks and the invalid block hash. After
reconsiderblock 9b71c783e9eebf9939c169dc2b5b18bc346c0b0fea19c9055e4e4f04363514a4
the chain was rolled back and is now synchronizing again. I looks like more people are on this wrong chain and also masternodes minting new blocks.Here are the relevant lines from my log-file for your analysis:
What you expected to happen:
Staying on the right chain and a smooth synchronizing
How to reproduce it (as minimally and precisely as possible):
What are your environment parameters:
I used the node version 3.2.2 and updated later on 3.2.3
Anything else we need to know?: