Release 40

Changes

• Fixed a fatal bug that rendered the entire Equihash and Ethereum families inoperable (all shares rejected for ETH, ETC, ZEC, BTG, BTCP etc.)
• Improved rejected share logging

Release 39

Changes

• Fixed two critical bugs with Monero v8 (Cryptonight v2 hardfork)
• Added AEON coin template
• Expose coin family through API
• Return 24h payments in API
• Console only logging in recovery mode
• Added miner earnings by day to API
• Made database access layer completely async
• Simplified SoloPaymentScheme reward recipients configuration
• Simplify ShareRecorder queue and use batch inserts to improve performance when database is running on slower disks
• Updated libcryptonight using INTEL assembly version for cryptonight v2
• Async-optimized ShareReceiver

Release 38

Breaking Changes

• The payoutinfo column has been removed from the database schema and the codebase. This field was only used for Cryptonote coins and was a source of endless frustration for the API and consuming web-frontends

Database Migration

Miningcore needs to be stopped before performing the steps below.

Do this for every cryptonote pool you are running (Monero, Bittube etc):

UPDATE SHARES SET miner = concat_ws('.', miner, payoutinfo), payoutinfo = NULL WHERE poolid = '<your-poolid>' AND payoutinfo IS NOT NULL AND payoutinfo != '';

when done execute

ALTER TABLE shares DROP payoutinfo;

And restart your pool.

Other changes

• Fixed a bug related to the upcoming Moneo v8 hardfork pow change
• Fixed examples for new configuration syntax introduced in Release 34
• Minerstats and Poolstats older than three months are now deleted periodically (Stats GC)
• Fixed a benign warning in Clustering Mode
• Fixed a Nicehash stratum protocol violation for Ethereum family
• The pool API now returns the coin displayname

Release 37

Changes

• Maintenance release
• Several minor performance optimizations and reliability improvements
• Added support for Minexcoin (MNX)

Release 36

Changes

• Added missing definitions for Digibyte-Scrypt and Verge-Scrypt
• linux_build.sh is once again executable
• Several minor performance optimizations

Release 35

Changes

• Fixes a crash in the API module

Release 34

Breaking Changes

Starting with this release, supported coins are no longer hard coded but defined as templates in configuration files. This change should make it much easier to support old and new coins down the road.

Important

Pool configuration files need to be updated to work with this release. Whereas you previously referenced a coin by its trade symbol (BTC, XMR etc.), you now have to reference it by its id in the defining template file.

Miningcore ships with a default template file coins.json which gets always loaded and contains templates for all coins that have been supported up until now.

Old

{
  "pools": [{
      "id": "xmr1",
      "coin": {
        "type": "XMR"
      }
  }]
}

New

{
  "pools": [{
      "id": "xmr1",
      "coin": "monero"
  }]
}

Important

Another notable change from previous releases is the name of the generated entry assembly. In previous releases the file was named MiningCore.dll, now it is Miningcore.dll. Be sure to update your scripts.

Other changes

• The codebase has been completely refactored, cleaned up, generics use was toned down and simplified where possible and additionally namespaces have changed from MiningCore to Miningcore (non camel-case version) for all source files.

Adding or replacing coin templates

To add new coin templates or replace existing ones - including the ones in the default coins.json - you can augment your pool configuration file like this:

{
  "coinTemplates": [
    "/path/to/mycoins.json"
  ],
  "pools": [
    ...
}

You don't have to manually include Miningcore's default coins.json in coinTemplates. This will be done automatically.

Coins are categorized into several distinct families:

• Bitcoin (ancestor Bitcoin)
• Equihash (ancestor ZCash)
• Cryptonote (ancestor Monero)
• Ethereum (ancestor Ethereum)

Release 33

Breaking Changes

• The clustering configuration has changed! The new shareRelays element resides at the cluster-configuration level as opposed to the old externalStratums element that used to live at pool-configuration level, which is completely replaced by shareRelays. You also don't need to specify topics anymore.

Example:

On the slave (relay) node:

"shareRelay": {
  "publishUrl": "tcp://0.0.0.0:6000"
}

On the master (receiver):

"shareRelays": [{
    "url": "tcp://relay1:6000"
}],

Changes

• A resource leak in the Stratum Client has been fixed
• Stratum Sockets now have TCP keep-alive enabled to prevent sporadic disconnects of slow miners before varDiff can tone down their difficulty
• The ZeroMQ based Master/Slave functionality now supports ZeroMQs Curve Encryption which can be configured using a shared secret known by Master and Slave.

Example:

On the relay node:

"shareRelay": {
  "publishUrl": "tcp://0.0.0.0:6000",
  "sharedEncryptionKey": "foobar"
}

On the master (receiver):

"shareRelays": [{
    "url": "tcp://relay1:6000",
    "sharedEncryptionKey": "foobar"
}],

The keys must match otherwise no shares will be received and recorded. Since this encryption is completely transparent to the Application there's currently no way for MiningCore to detect that the crypto-handshake failed. But sure to test your setup carefully.

Release 32

Changes

• Maintenance release with several bugfixes
• The build-system has been simplified and dotnet publish -c Release --framework netcoreapp2.1 -o build is enough to build the project on all platforms

Release 31

Changes

• Fixed several stratum-related resource leaks that resulted in significant performance degradation over time
• Performance optimizations for the Monero family of coins
• Added support for Bittube (TUBE)