A lesson and in responsible disclosure and software development:

How PIVX continues to develop solutions for the blockchain ecosystem despite BITG and Lunar Digital Assets dropping the ball in proper bug disclosure protocols.

There has been (continued) coverage by larger crypto media outlets online around PIVX, a reported vulnerability, and the presumed “savior” who announced this to the world, BITG (which is a fork of PIVX).

Let me preface this article by saying this:

The PIVX developer DAO team has prided itself on creating standards in the crypto realm. By that, I mean, they have worked tirelessly to create a modicum of software standard when it comes to:

  • Code
  • Code audits
  • Code descriptions
  • Bug/Exploit validation
  • Bug/Exploit solution development
  • Bug/Exploit & Corresponding solution pre-announcement to fork devs
  • Bug/Exploit Documentation and Solution Pull Request Notification to the Public.

In ANY realm of software development, there are standards, procedures, and proper guidelines for doing things in a manner that well, allows a codebase (an especially open-sourced software) to actually be viable, usable, and maintain a manner of longevity. By putting these practices into place, it makes updates, code auditing, bug squashing, and solution architecting easier, more efficient, and as a result, is better for the network(s) that software serves.

Put another way: when developers develop, and use solid standards, and document their code, and remain level-headed as they work through audits, bugs, and the like — it supports the project, ensures the stability of the ecosystem using it, and demonstrates a level of professionalism and respect for the work being done and those using it.

PIVX has become one of the most trusted and used codebases for other projects (be them other open-sourced projects or even internal closed chain networks), and a large part of this is due to the ability for others to actually be able to use, implement, and understand just WHAT is going on in the codebase. Is there work to be done? Absolutely. Are improvements needed? Always. This isn’t new to software development and isn’t unique to PIVX. It’s an ever-ongoing adventure of developing, mitigating risks, improving, and deploying, all while maintaining the core.

Turning our attention back to BITG and the article(s) / statements made over the past 72 hours

Let’s analyze the statement about how BITG “identified” a vulnerability in PIVX

To start: Let’s look at the difference between identifying and observing:

identify

verb iden·​ti·​fy | \ ī-ˈden-tə-ˌfī , ə-\ identified; identifying

to establish the identity of

to say or prove who or what someone or something is:

observe

verb ob·​serve | \ əb-ˈzərv \ observed; observing

to come to realize or know through consideration

to take notice

In the writeups and articles and even in BITG own discord, Han Yoon/Lunar Digital Assets /BITG make the claim that they:

  • Identified a vulnerability
  • Were the FIRST to identify said vulnerability
  • Confirmed that this vulnerability is present in ALL PIVX forks.

Taking all the above into consideration and in all the provided sources (from Han/BITG)

  • BITG observed some behaviors in their network, others, and PIVX.
  • Nowhere do they or have they identified just WHAT is causing or leading to this issue.
  • Nowhere did they or have they disclosed they could replicate the issue.
  • Nowhere did they or have they validated that this is occurring in ALL PIVX forks.

Next, we turn to the online statements praising BITG for it’ solutions and fixes.

Before we do, we need to understand the difference between “minimizing the effects / temporary patch” vs “developing a network solution that others can use and implement into their code as a solution

In Han / Team Lunar / BITG article (posted to hackernoon) He quotes:

“Why was the BitGreen devs able to halt the attack in a few days, while PIVX has knowingly let this exploit go on for god knows how long?”

To the best of our understanding, the attacks in BITG were not halted.

If anything, what BITG ended up quickly attempting to do was minimize the reward amount that the individual was able to get per block.

Put another way, what BITG did was drop the staking block rewards. This does not = halting the attack, especially from a software solution perspective.

The BITG solution/fix (halt) to what they apparently observed occurring on their network?

You can find them here https://github.com/bitgreen/bitgreen/commit/6fa121a7f66b451194f29e2863e6b7746496112c

In summary, what BITG did was this:

  1. Drop the stake rewards (to 1 coin per reward)
  2. Cut off Masternodes
  3. Make a minimum UTXO size. Looks like they set it to 1000, then reduced it to 200 on another commit
  4. Increased to the blocktime from 1 min to 2 mins (which has the effect of reducing the block reward in half again).

All-in-all, there was a load of steps and changes to the codebase to reduce the ROI of staking (which, in turn, “minimizes” the rewards that an individual was receiving).

Indeed, at best, these are a stop-gap measure. Again, these steps are not what in the software you would describe as a fix.

Their “final” fix is yet to be implemented. Could this be why Han Yoon / BITG — asked PIVX for a solution?

This begs the question if indeed BITG had found a solution (or rather, been able to HALT the attack, which would indicate a fix), why were they (Han) coming to PIVX to see if there was “a solution?”

It also appears that BITG states they will be forking (again) to another codebase ← perhaps this is their “solution?”

Though, this is not what the public sees in these articles that then, in turn, is reposted to places like CoinTelegraph and Coindesk.

Instead, the narrative comes out as:

  • BITG “identified” an issue
  • BITG found a solution
  • BITG is “safe”
  • PIVX + all 200+ forks are in trouble
  • PIVX lied to the world.

Instead, by unpacking the above…what BITG really did (and/or Han / Team Lunar Digital Assets): Is potentially put countless crypto projects at increased risk by publically publishing observations without verification and/or a solution for said issues.

BITG publically made known an observable anomaly occurring in their chain, PIVX, and “others” Yes…indeed, they WERE the first to go public. However, that does not mean that PIVX was not aware, and was not already working on a fix in a proper OPSEC manner.

In fact — BITG:

  • Nowhere do they or have they identified just WHAT is causing or leading to this issue.
  • Nowhere did they or have they disclosed they could replicate the issue.
  • Nowhere did they or have they validated that this is occurring in ALL PIVX forks.
  • Nowhere did they or have they disclosed that they had a working solution for this issue.
  • Nowhere did they or have they disclosed working with other projects prior to going public in an attempt to mitigate further attack risks and/or open projects to more vulnerabilities.

Instead of following some fairly basic standards/protocols (call it even being considerate to the crypto-community at large), they pushed out an article that:

  • Potentially put MANY OTHER projects at risk.
  • Publically disclosing observations WITHOUT any identification of the root problem, NOR without any proper solution, NOR without discussing this with the other projects that may or may not have been affected is just sloppy.
  • This only increased the potential attack vector, bringing more eyes/awareness to a potential issue which might allow more individuals to try and use this mechanism to skew their own stake rewards).
  • Spread Misinformation, FUD, into the mainstream

— —
The issue in the above scenario has NOT been publicly shared yet by the PIVX developers.

Proper OPSEC usually demands that one does not share possible bugs or exploits till:

  1. Proper diagnosis of the situation has been made
  2. Proper solutions have been created
  3. The solution is tested and validated to ensure network stability.
  4. Other projects have been properly notified
  5. Other projects have been given sufficient time to implement their own changes

For an example of this process (done right), have a look at what the PIVX developers did to mitigate the Fake Stake exploit.

— —

Suitable fair disclosure has been made to as many of the 700+ forks as possible.

PIVX will continue to remain true to the values of open source collaboration and will continue to uphold high standards of open-source software development practices.

WE invite forks of PIVX to come in if they need help, though it will not come from core devs.