There seems to still be some confusion and/or questions about the BRS 2.2.7 software and it’s trustworthiness since the PoCC decided to step away from their roles as the lead Burstcoin developers earlier this year, so below I’ve laid out some steps to test the software for yourself.
It’s important to note, that this method is only reviewing the changes from 2.2.6 to 2.2.7. It is not a complete software review.
Step 1: Review
The first step would be to review the changes. Presumably the PoCC didn’t have any malicious intent before this release, so first look at the diff between 2.2.6 and 2.2.7. To do that, check out the commit on GitHub.
https://github.com/PoC-Consortium/burstcoin/commit/0cae253fd4ca46ea8d8c86a83fd440b5e56e99ef
You can see from this, that there were only minor changes between these releases that deal with communication with peers. It looks like peers are now removed if they’re not responding correctly.
Step 2: Download
Now that you’ve done a review of what’s changed, let’s compare what’s in the zip file that was released and the actual source downloaded from GitHub. This assumes that anything could have been compiled into the application and uploaded in the zip file. We just want to make sure everything is on the up&up.
To grab both the source files and the zip, download them from https://github.com/PoC-Consortium/burstcoin/releases
GitHub creates the Source zip and tar.gz files from the source code, so we can assume everything there matches what’s publicly visible. The burstcoin-2.2.7.zip file is an extra pre-compiled version that was uploaded by Rico666 to save you the hassle of compiling it yourself… but that’s what we’re going to do next!
Step 3: Software Prerequisites
Now that we have the source code, we’ll need something to compile it. The BRS software is written in Java, so we’ll need Java’s JDK v8 (the same version it was written in) to compile it.
The Java Development Kit can be found here: https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Next we need to make sure that the JAVA_HOME variable is set up in your PATH. The simplest way to do this in Windows 10, is to click on Home icon and select Settings. From there, input “path” in the search field and select Edit the system environment variables.
On the next screen you’ll see User variables for Username and System variables. Under the System variables section, click New… and add in a variable JAVA_HOME and browse for your JDK install folder. This will let your system know where you have the JDK installed.
Next up: Maven
The BRS code is compiled with Maven. Maven is a software project management and comprehension tool written by The Apache Software Foundation. The source code for BRS lists that it’s compatible with version 3.5.2, so we’ll grab that from the files from the Maven archives: https://archive.apache.org/dist/maven/maven-3/
Under the 3.5.2 folder, find the binaries folder and download either the tar.gz or the zip file.
Once you have the correct files, follow the instructions for Installing Apache Maven. It’s pretty straightforward, just unzip the files somewhere on your hard drive and add it to your PATH environment variable.
To add it to your PATH, follow the same method as the JDK, except this time you’re going to edit the “Path” system variable that’s already there. If you unzipped Maven in C:\Program Files\Maven for example, add C:\Program Files\Maven\bin.
Test that you’ve installed it correctly by opening up a command prompt and typing:
mvn -v
If this doesn’t work, see the tips on the Maven Installation page.
Step 4: Compile
Now if everything went correctly, it’s time to compile the application! Unzip the source code for BRS 2.2.7 to something like C:\BRS_Source, then unzip the pre-compiled version to C:\BRS_Packaged. We’re going to compare the Java classes that are compiled here to verify that they match.
Open up a command prompt and navigate to C:\BRS_Source. Now we’ll compile using Maven.
mvn package
Maven will now download and compile all of the dependencies as well as all of the source for BRS. At the end of the process it’ll run some test scripts to validate that everything is working as intended. For me, the actual build fails, but that’s ok. I’m not really worried about a successful test here since I’m not developing the software. I’m not going to spend the time debugging. I just want to know if the classes that are compiled match the package provided.
The build process creates a number of class files in C:\Burst_Source\target\classes\brs.
Next, change directories over to the pre-compiled version C:\BRS_Packaged. In this directory is the final burst.jar file that you’d get if your build didn’t fail like mine did. Java allows us to extract that package with:
jar xf burst.jar
Final Step: Compare
Now, what we’re finally interested in is a binary comparison of the two folders. The first folder is the one we created with the Maven compilation process. The second is the one extracted from the burstcoin-2.2.7.zip file downloaded from GitHub.
To do this, open up both with the diff program of your choice. I use WinMerge, but any program capable of comparing binaries is fine.
What’s the Verdict?
What’s the verdict? Besides writing waaay too much info here? Everything looks fine!
It’s understandable that many people are still asking if 2.2.7 is safe to use, since I would assume a large portion of the community just sets their miners up for a while without checking back in. Many people may still not know about the whole “drama” with the PoCC in the last month.
If you still have questions. Please visit the Reddit board or Discord channels and be sure to ask the community.
Leave a Reply