How to properly "recover" a Multichain network

Question

Hi.

I want to recover the Multichain to an earlier state since we somehow lost a node (and therefore a miner private key) and cannot continue from here.

I managed to use the following commands to set the blockchain to an earlier state:

• pause
• setblock (140)
• clearmempool
• resume
• pause
• setblock (hash of the new fork)
• clearmempool
• resume

Unfortunately the node is not able to mine on the new branch and I also cannot create any transactions (e.g. create stream), since the following message is returned:

"Safe mode: Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

 

There is indeed another node in the network ( I will also need to realign this node at a later point in time), but for now the primary node should not care about this other node because it is not listed in the "listpermissions" (only our own node address is returned here) and also "getpeerinfo" returns empty.

 

Nevertheless I am not able to create any transaction because of the mentioned message above.

 

When I do a getchaintips, it shows that I am actually in the correct fork

 

        {

            "height": 140,

            "hash": "0089f1d9af5715a3e0f108c6ec0bed31ac5cbdc2db7bbc650a0e5951a7e117b9",

            "branchlen": 0,

            "status": "active"

        }

But nothing is going forward here

 

getinfo:

 "version": "2.0.7",

        "nodeversion": 20007901,

        "edition": "Community",

        "protocolversion": 20011,

 

Some hints?

Comments

Thanks, this sounds like a bug. I've asked the devs to take a look.

Answer 1

This error appears when you have a long invalid fork. In this case the node suspects something is wrong with its own database, because other nodes mined on that "invalid" branch. Node prevents (almost) all RPC calls and returns this message, just in case...

In your case, the database is OK. I suppose you somehow made the branch with blocks mined by the lost node invalid (by setting bantx, for example), otherwise MultiChain would choose that branch after setlastblock or resume.

If this is correct, it is normal reaction of MultiChain in "Safe Mode". You can disable safe mode by setting

-disablesafemode=1

Please note, you should have this switch until your new branch (without block mined by the lost node) becomes longer than that invalid branch, After that you can remove it.

Comments

Hi Michael, you are right, to avoid always picking the long fork I banned a tx.
I will try disabling the safe mode and let you know if that worked out.

---

Hi Michael, thanks, it seems to have worked. Some comments:
- it would be great to have this "disablesafemode" as a setruntimeparam in the rpc api, otherwise you need to log into the node (but maybe this is intended?)
- is it somehow possible to prune all other forkes, or should I just ignore them?
- what do you mean with "longer"? A higher block number or the actual fork length?

---

We'll discuss internally whether it makes sense to add "disablesafemode" as a setruntimeparam in the rpc api

As for other forks, you can ignore them. In version 2.3.5 (still in beta) we add "count" parameter to getchaintips, so you will see only several most-recent forks.