The official BSOD.PW Press Release regarding SIN

Over the past few days, unhealthy things have happened around the mining of the Sinovate (SIN) coin, and the bsod.pw pool finds it necessary to notify the crypto community.

Most likely, there is a vulnerability in the SIN source code, the implementation of which leads to the loss (burning) of the masternode reward.

A more detailed explanation is as follows:

1. Daemon sends Getblocktemplate command to burn the reward.
2. The reward is sent to the address for burning.
3. A mined block is accepted by the daemon and the rest of the network as correct.
   As proof — we publish a screenshot of this command.

Unfortunately, at the time of publication of this article, the vulnerability is not fixed and has a critical status.

In addition, in the process of studying the current SIN situation, we found the following suspicious things:
The unknown pool mines a significant part of the SIN blocks, while the entire masternode reward goes to a set of the same addresses. As a result, the rest of the masternode holders receive less profit.

Unfortunately, at the time of this writing, the official explorer incorrectly displays information, so we provide links with examples of such blocks to one of the alternative explorer:

https://icemining.ca/explorer/SIN?height=174886
https://icemining.ca/explorer/SIN?height=174884
https://icemining.ca/explorer/SIN?height=174882
https://icemining.ca/explorer/SIN?height=174881

The address of this pool is not known to the popular PoW coin monitoring resource:
https://miningpoolstats.stream/sinovate

We note that almost simultaneously, a significant part of the hashrate from many pools went in an unknown direction. In the screenshot below, we have identified this time interval with two parallel vertical lines, and you can see that the hash rate has decreased significantly in the pools “rig.tokyo”, “icemining.ca” and “bsod.pw”.
Therefore, the accusations that this hashrate belonged to the bsod.pw pool do not make any sense to say the least — it does not make sense for us to direct our hashrate to another pool, thereby losing commissions and helping competitors to find blocks.

Also, in the screenshot in the highlighted box, you can see that at the moment more than 60% of the network hashrate is owned by an unknown private pool.

First of all, we would like to draw attention to the fact that bsod.pw since 2017 has been a popular pool for mining and solo mining of many well-known cryptocurrencies. Such as LUX Coin (LUX), Raven Coin (RVN), Bitcore (BTX), Vertcoin (VTC), VEIL and many others.

Pool support is possible thanks to the commission for the mined block (0.9 / 1.9%). Therefore, the pool, along with the developers of cryptocurrency, is interested in the popularity and high market rate of a particular cryptocurrency. Accordingly, there is no point for the pool to act in a destructive way on a project that is in the listing and makes money.

The SIN development team is currently unfoundedly blaming our pool team for the error. We’ve even received direct threats of causing physical harm from the SIN management.
Here’s the log of one of the team members of the bsod.pw pool with the SIN project manager (nickname in Discord Cryplander#6325)

On June 07, Cryplander # 6325 wrote about hashrate migration to a private pool and confirmed the presence of a bug with Getblocktemplate:

In the screenshots above you can see that there was an absolutely normal calm discussion with no signs of a trouble.

But already on June 08, the SIN team on its own resources unreasonably began to blame the bsod.pw pool for attacking the blockchain of their coin, and one of the pool employees received personal threats. Below you can see screenshots of this chat:

In the discussion, Cryplander#6325 actually wrote the phrase “I’ll kill you”, but immediately deleted it. The corresponding screenshot has been preserved.

Considering the situation described above, we are delisting SIN from the bsod.pw pool and reserve the right to apply to law enforcement agencies with a corresponding statement on the fact of life threats — we have the personal data of the person who threatened our employee.