I got a chance to debug PIVX clients that were going missing. Apparently they use some double-broadcast ridiculousness to get into an ENABLED state. I'll release a patch shortly so you can issue a single broadcast and then run the phantom daemons.
If you want more technical details, they create a catch-22 scenario where a broadcast goes out, is marked as PRE_ENABLED but the code doesn't respect PRE_ENABLED. When the network tries to update, it rejects it because the masternode isn't ENABLED, but it can't get ENABLED until it accepts the update. I've got a work around that sends a broadcast that instantly goes to ENABLED and then everything works fine.
The downside, you'll need to run the broadcast command and then run the phantom daemon -- so it's two steps vs. one step for DASH -- but still easy.
Update should be coming in a day or two.
best,
break
Hey, it seems like you are doing proper work on this container-- however I have heard there is some concern from Bittrex security regarding your tool's potential ability to spoof existing MNs. My understanding is that MN peer nodes don't validate a static IP of the MN set at the time of configuration. Trex security have apparently been lurking your discord and they are worried your tool can be modified to Sybil-attack MN networks for easy forking, vote manipulation, or double spend via Sybil-falsified instantsend quorum.
Additionally some scanning of the Windows binary has revealed TrojanDropper.Dapato.zby which I'm hoping is a false positive.
https://www.virustotal.com/en/file/34d5553bca53dd84560f4779071bf5267bb9f1755d4b2dc4208f576d4a977ac8/analysis/1556570810/I apologize for having to edit my neutral post above to a warning but a lot of people follow blindly what I say and I didn't want to be responsible for any losses incurred by people testing your tool without full awareness of the risks.