• Thank you for your input for the last few days regarding the list of exchanges you want to see DSTRA in.
    These are our targets for fundraising going forward. Learn more

PoSe, Deterministic Masternode, Dstra


Junior Member
Staff member
A couple of week ago I made a little guide on how to run multiply dstra masternode using a single IP address. A way I have used on many other coins also, working just fine. chunnorris came forth and said that it will not work on all coins; you will get the PoSe-banned status on your second Masternode on some coins.

And it is absolutely true; it does not work on all coins. It does not work on coins running Deterministic Masternodes, and it might not work on a few “normal” masternode coins. It depends on how much check is included in the code. It works on a lot of coins. I have yet to find a “normal” masternode coin where it does not work.

That being said PoSe (Proof of Service) is an old issue of masternode. Basically it revolves around, how to check if a masternode is actually contributing to the network and available for coin mixing and instandsend and not just a “lazy masternode”, hanging around collecting its MN reward but not actually doing anything. Basically I think its all horsecrap; the time and effort to make a lazy masternode, contra just running your masternode, is counterproductive on all accounts. You probably have an incentive to make the coin/chain run smooth, or else you would not be running a masternode on that coin in the first place.

Several checks are made on “normal” Masternodes to see if they run. Normally when a masternode is started you have these status it can be in; PRE_ENABLED, ENABLED, EXPIRED, OUTPOINT_SPENT, REMOVE, WATCHDOG_EXPIRED, POSE_BAN, VIN_SPENT and POS_ERROR. They will probably be defined in most coins, however it differ widely if a function is available to bring them in these stats and what the requirements are.

In DSTRA all these stats are defined, however functions are only available for ENABLED, EXPIRED, REMOVE and VIN_SPENT.

Enabled; when you start your Masternode. Some checks are done in Dstra, including collateral amount and confirmations. This needs to be 15 or older in Dstra.

Expired; If your masternode does not answer pings within a given time frame, it gets the status Expired. This is the so-called grace period, inserted to avoid two things, bad connections and DDOS attacks. That last one I never heard of actually happing, but imagen if you have a very valuable masternode coin, you DDOS some or all other Masternodes, and you would be the only one left to receive MN reward. Speculation I think! Thus a grace period is installed, so you remain in the masternode list and receive reward within the given timeframe, despite not being online. In Dstra it is 2 hours.

Remove; when you have been removed from the masternode reward list. In dstra it is 2h 10min. However you first get removed from the local masternode list after 4h 20min.

Vin spent; Your collateral amount is no more available in the block hash you have specified for your masternode. E.g you spend some, or all, of your collateral amount.

In “normal” masternode, each masternode keeps a local individual list of Masternodes on the network (the file mncache.dat). A new masternode gets into this list by creating a collateral transaction and sending a P2P broadcast announcement to the network. By regularly sending a broadcast ping it retains it place on the list (ENABLED). In Dstra this is every 5 min. If other masternodes does not hear from you, they will ping you. In Dstra this is every 10 min, and if you don’t answer after 2 hours you will be tagged EXPRIED.

In May 2018 DASH introduced Deterministic Masternodes, gradual implanted during the last 6 month. I think 70-80% of the masternodes is now running Deterministic Masternodes in DASH. A concept where you keep the masternode list in the blockchain and not as an individual list on each masternode. Many more radical changes is in this. Quite a good read, and good changes. There are many pros, and some cons, in this.

PoSe-banned, while rarely seen in “normal” masternodes, either because it is simply not implanted in a coin (like in dstra) or the requirement to get it is difficult, it is now much more easy in Deterministic Masternodes. The reason for this is that IP and port is now recorded in the masternode list, in the chain. Any other masternode trying to get into the list, having the same IP, as an already existing masternode, will get the PoSE-banned status.

Other coins have of course already copied this concept of Deterministic Masternodes (Standard DIP002, DIP003 and DIP004), things move fast in the crypto-world.

Cannot say I’m in agreement with this approach. I like a lot of things in this masternode type, for sure, but one Masternode per one IP, is simply old thinking, and its not how the world works anymore.

Imagen if every mobile phone needed its own frequency! Imagen if every electric appliance needs its own power line directly to the power plant! Imagen if every inbound connecting to your house needs its own cable! Imagen if every resident in a house need their own post address!?! Even IBM, who have like millions of IP assigned, does not have millions of cables into their buildings, much less a private user, they do not have two cables into their house, if they have two IPs. Mobil telephones does not have their own frequency, they share frequency, with their own identifier.

I see little reason why one IP can/ should only host one Masternode for one coins. What is the thinking behind this is Deterministic Masternodes I wonder? You cut the power to a place, you take all down. You cut the cable to a place, all connections (ips) goes down, because they run on the same cable?!

Where did free markets and de-centralization go? Smells like centralization and artificial rules. Thoughts?
Last edited: