How to Unban a POSE_BANNED Masternode

Masternodes are required to be up and running 24/7. The network keeps track of “Proof of Service” with a “PoSe score”. The optimal score is 0, and the worst score corresponds to the number of registered masternodes. The network bans a node with a poor score after it reaches the network’s banning threshold.

If banned there are several things you can do to unban it and prevent it from happening again. Make sure the VPS is on a reliable host that is always online. Also make sure that the VPS has the required dedicated resources and specifications. Make sure that the node is synced to the right chain and the right block by logging into VPS and using syscli commands (or syscoin-cli if syscli not enabled):

syscli getblockcount

If not synced, stop, restart, and reindex the node with:

syscli stop
syscoind -reindex

Finally, and sometimes this is all that is needed: from QT console do a protx_update_service command with 5 arguments. The arguments are:

Protx hash
IP:Port
masternode private key
“”
fee source address

Protx hash (your original masternode “provider registration transaction” or ProRegTx hash) is obtained from QT by right-clicking on the masternode and selecting Protx hash.

IP:Port is of the VPS.

You can retrieve the masternode private key from the VPS using this command in VPS:
cat /home/syscoin/.syscoin/syscoin.conf | grep masternodeblsprivkey

The next argument is the masternode payout address. To keep it the same, use “”, to change it, insert the new payout address.

Lastly, the fifth argument is the syscoin address in QT that will fund the transaction. The fee is very small (typically less than 0.00001 sys) but this address needs to have funds in it (it cannot be zero), and also, this address cannot have too many past transactions (more than a few hundred) or the protx_update_service transaction will be rejected as too large (too many inputs). If left out, this argument defaults to the payout address, instead of to the orginal feesourceaddress, so it is best to go into coin control in QT and select a small, funded change address with minimal transactions on it.

DO NOT SHARE MASTERNODE PRIVATE KEYS WITH ANYONE. DO NOT GRANT ACCESS TO VPS LOGIN OR MASTERNODEBLSPRIVKEY COMMAND TO ANYONE. DO NOT USE REGULAR DISCORD DM FOR SUPPORT, AS THESE ARE ALL SCAMMERS IMPERSONATING ADMIN ACCOUNTS. ONLY USE THE CREATE TICKET SYSTEM FOR SUPPORT.

NOTE: IF YOU COPY-PASTE COMMANDS, BE SURE TO CONVERT THE DOUBLE QUOTES FROM THE STYLIZED FORMAT IN THIS POST TO PLAIN UNICODE (U+0022) DOUBLE QUOTES IN YOUR TEXT EDITOR FIRST, OR THE COMMANDS MAY NOT WORK.

Hello, there must be something generally wrong, I have been running a masternode for about a year.
And i never had POSE_BANNED problem, but after upgrading to latest version in november i get posed_banned every time just before payment.

This should not be happening. On-chain stats for the past week show the rate of banned nodes is down to 1.4%. (Although I cannot say how often node holders are running the update_service command to maintain it that way). I would double check your VPS specs, should be 20.04 LTS, 64-bit CPU, 4 cores, 4gb RAM, KVM, 80gb disk space. You can also wipe and reinstall the node using the Syscoin LUX Masternode script (posted 30 April 2021 in Tutorials section), beyond that, there is the Discord create-ticket channel for secure support.

I was asked to post an example of the final protx command syntax for QT console, it looks like this (again, substitute plain unicode quotes for the stylized quotes):

protx_update_service 21b2… xxx.xxx.xxx.xxx:8369 f2b0… “” sys1q2s…

I don’t understand what is wrong. My PoSe Score is 0 all the time, but at the moment where i reach the block where payment is, i get posed banned. My server is latest Ubuntu 20.4, 16 GB ram, 8 cores CPU, and 150GB disk, running on VMware 7.1. enabled IPV4, and IPV6 ( not used) my IP 194.182.21.242:8369

@GJT67 I wish I could tell you what is going on there. That is not happening with the vast majority of nodes. I would think the VPS log file would say something that would explain it, particularly because every log entry is time-stamped. Also, you may need to modify which peers you connect to. I would go over the log file and the peers with a support ticket.