I don’t recall saying there wasn’t an issue or some aberrant behaviors occurring.

You also did not let “all” the PIVX devs have time to respond. It appears (in the unfolding of events) that you barely let 36hrs transpire before having an article go public that contained a myriad of misrepresentations about PIVX, it’s developers, and the work being done. So to say “NO devs were willing” again is not true.

I also (from my observations with any type of potential vulnerability, bug, etc…not specific to this current scenario)) curious as to why you in < 24 /36hrs elected to publically blast information that could be used by any potential attacker to hit multiple chains.

Usually (in software dev) as a team, if you find a vulnerability and or bug, you don’t publically tell everyone, ESPECIALLY if it has any remote possibility of affecting your network, let alone other(s). That’s called being responsible, and pro-active. Minimize the potential risk, calculate the solution, repair, let other projects then get an advanced notification, and then push the solution live.

When someone (third party) comes presenting an issue (call this bug reporting), there is a sequence of due processes that are all designed to ensure the security and safety of the network, code, and community as well. This ALL takes time. Now, when someone comes in reporting a presumable bug and then “threatens” to go public and let the world know <- that kind of demand is NOT going to be responded to. Holding developers hostage with what may or may not be valid observations and or bugs …. not sure if you’ve worked in software teams/etc before, but I can’t imagine that’s going to go well for any future conversation, let alone doesn’t sound like “trying to be polite and/or help clear PIVX of anything” as you indicated you were attempting to explore.

But back to “discovering” bugs/issues/abnormalities. We’ve done this (and seen this) in PIVX a few times, where either PIVX developers (or other clones/fork developers) found potential bugs, and work was done to mitigate that bug, and then shared to as many forks as possible, BEFORE any public repo push, let alone public disclosure.

As has been presented, you use(d) the term bug rather broadly in your article, where it appears there was a myriad of factors at play (not limited to any occurrence observable in PIVX). In fact, you appeared to have confused the situation by referencing that this reported “bug” was in fact the Fake Stake Attack (that had not been fixed, again….indicating and insinuating that the PIVX developers were lying).

There were abnormalities at play with BITG it appears that may or may not have been caused by their coding, commits, etc…which may or may not have anything to do with the behaviors being observed in the PIVX network.

While the PIVX developers tone is his choice to make, there are data in his statement to parse out:

1- PIVX devs work for PIVX (not forks or clones). Expecting a response from them in < 24 hours (or even <48 hours) is pretty incredible. They code and focus on code (and PIVX). Also expecting a dev from another project to be able to drop what they are doing to look at your code and or a potential bug that may or may not even be occurring in their own network, is another thing. It seems you did this with Peercoin (and they didn’t help you either, Yes, it appears their network wasn’t experiencing the same issues…however, at the moment when you began to ping the PIVX devs, they as well would need to begin the process of ascertaining whether or not what you are reporting is a) indeed going on in PIVX — they’re not just going to take your word for it, b) identify if it’s related to any of the work they were currently engaged on/working on — This doesn’t happen overnight. )

2- Multiple pings (and emails) to the PIVX devs (IMO) only really serves to stir the pot of annoyance. Again, notice I’m not saying I condone the tone or manner of dialogue..I’m merely inferring here the past scenario.

3- Asking for a “quick fix” to some “anomaly” is vague at best and again, a “quick fix” is never ideal in Crypto. Let alone when it comes to a potential vulnerability. Asking that of a Developer basically screams “scam” and “these guys aren’t serious”. Again, notice I didn’t say it’s right or wrong, just working through the nuances here.

4- Now, at this point, data is passed back and forth to you and members of the community in PIVX. Information is relayed to you that states the PIVX devs are aware of SOME issue (notice, there is NO indication of what “that” issue is, or EVEN if it pertains to the observations of the network, or that it even has anything to do with what your “client” is experiencing, the one you said you needed a quick fix for). Just that they are aware, and have a solution designed to rollout in v4.

5- Cycling back to “bug”….and where you seem to be hanging your hat around the untrustworthiness of developers (PIVX in particular). Again, proper OPSEC … if a team internally identifies aspects of code that allows for anyone to game it (is this a bug/vulnerability/exploit)….what is in the best security measure for that team to do? As it appears in PIVX, there is no “bug” in the sense where new coins are being created, or the chain is being forked, or that the network is being hacked, etc. (my words). There has been an ability by someone(s) with at least 11k+ PIV (not 87 mind you) to skew the block rewards towards lower value inputs (allowing them to game the rewards, earning MORE than what is normal, but not statistically impossible). Let’s say this has been going on and potentially gamed (it’s possible) since the birthing and evolution of Proof of Stake. And along the way, more/different consensus models and algos have been created and iterated to arrive at a more FAIR consensus model (in that regard, one that would prevent this type of behavior from being able to occur).

Now if the PIVX devs did observe this beginning to occur, and indeed were aware, and were working on it, again — good security measures would demand a viable solution be created and then SHARED with other projects BEFORE then publically pushing any solution (because once you push it to the repo, then the public eyes are on it). There is no “falsehood” in not disclosing that to the public. There are proper safety and protocols.

You seem to indicate that the Dev Lies to public & blamed the removal of one line in code for those issues “over there” but not in PIVX.

Can you please show me where the PIVX dev lied?

I guess what I’m seeing is proper internal OPSEC from PIVX developers, and probably (now) what will occur is we’ll see a multi-step release (rather than one) now that this article has gone forth opening up a wider potential attack vector to many projects. Time will tell of course!