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.
There are no trojans in the binaries on git, that's for sure. But, of course, never take some rando's word for it, check the source and for the love of goodness, compile it yourself - the docker images make it super simple. Other than that, the phantom should NEVER require a collateralize private key, so if anyone suggests otherwise, don't trust them. I spent a lot of time on the architecture to make sure that private keys stayed in the wallet and private.
best,
break.
)