Own Mining Pool Guide

Guides

• Getting Started
• Configuration
• config.json
• daemons.json
• coin.json
• pool.json
• default.json
• software.json
• FAQ
• Donation
• How to ask questions and report bugs?

Misc

• Pools
• Coins
• Master Plan

Developers

• Developer's Guide
• Developement Model
• Developer FAQ
• Technical Documentation

 

Getting Started: Windows

Hüseyin Uslu edited this page on Dec 17, 2016 · 8 revisions

Requirements

• git
• Visual Studio 2013

Getting the sources

You can download the sources using git;

git clone https://github.com/CoiniumServ/CoiniumServ.git

cd CoiniumServ

git submodule init

git submodule update

Building

Once you got the sources, you can compile on Windows using Visual Studio. First navigate to sources folder and open the CoiniumServ.sln in build\ folder.

Set build mode to either Debug or Release though you are advised to use Release mode for production environments. Use the Build ~ Build Solution (F6) menu to start compiling the sources.

You can find the executables in either bin\Release or bin\Debug folder (based on the mode you selected).

Then you have to configure the server to get it working.

git configuration

Line endings

In your .gitconfig, you need to set core.autocrlf to input, like so:

git config --global core.autocrlf input

This will convert line endings to LF when committing (the standard) and back to whatever your system uses when you pull. Also, GitHub's help page lies to you about this; it is actually correct to use input on all OSes.
If you don't want this to be the top-level configuration for git, just remove the --global bit (but make sure you change it when your current directory is in a/the coinium repository). If you choose to do it this way, you must make sure it is set on your copy of all coinium repositories (main/documentation/site/etc.)

Forking

See here for help. Once you've made a fork, add a remote repository pointing to the primary upstream repository with:

git remote add upstream git://github.com/CoiniumServ/CoiniumServ.git

Then you can continually use git pull upstream master to keep in-sync with the changes made upstream.
Only after you pull upstream into your master should you push to your fork and open a pull request. This is to prevent giving us a bunch of extra work having to ensure that you didn't screw something up. It also makes it easier to see what you've changed.
If you are going to delete your fork, you must delete or close any pending pull requests (or wait for them to be merged). GitHub doesn't like it when you do that.

Conflicting merge commits

When merging a conflicting branch with upstream, do not remove the automatically-inserted list (in the commit message) of conflicting files.

Pull requests

A pull request (PR) is the primary way to push your changes upstream. We encourage you to send us anything that you deem appropriate for the master branch. We do not accept requests from a fork that is not up-to-date with upstream, so please don't send them unless you're fully up-to-date (this is to prevent rogue merges where one branch breaks something upstream, due to conflicting with upstream or (more often) in some other obtuse, generally unexplainable cases). If you need help sending a PR, see here.
We will typically only merge a PR when it is described adequately and follows the design and coding style of the repository.
Commits/PRs we will (typically) not merge:

• With commit message(s) "Edited ... via GitHub": because we're not going to test or traverse your diff in an attempt to understand your commits without a summary - unless we feel like yelling expletives at our monitors. There is a text box for the commit message below the edit box: use it. Or get a proper git client and make proper commits like the rest of us. These kinds of commits are explicitly refused due to not being able to tell what the commit does in commands like git log (without consulting the diff).
• With no or inadequate descriptions (sometimes you may pass by being descriptive enough in commit messages, but it is best to properly describe a PR. Even a summary of the commits will suffice, though this does not exclude you from writing proper commit messages in the first place).

A proper commit or PR will:

• Reference any issues (#XYZ in the commit or PR description, where XYZ is the issue number) that have been fixed (or for other reasons).
• Aptly describe what has been fixed/changed rather than, for example, "ponies weren't working right", where "ponies weren't working right" has presumably been 'fixed'.

A PR's description is best kept as a summary of the commits therein. Rule of thumb is:

• PR descriptions are verbosely descriptive summarisations.
• PR titles are a conciser version of the description.

If you want to avoid an active PR from picking up all of your commits to your master branch, you should work in a separate branch and only merge back to your master when the PR is closed (or if you want to include the commits from the branch in the PR). This can also be prevented by setting the PR's range to end at the last commit made, though in that setup you can't put any more commits in the PR since the range stops at a specific commit rather than the entire master branch.

Locating configuration files

Let's assume that you have downloaded CoiniumServ to

/home/user/CoiniumServ

Your config files will exist in one of the following locations based on the mode you compiled the project;

/home/user/CoiniumServ/bin/Debug/config

/home/user/CoiniumServ/bin/Release/config

Global configurationGlobal configuration file hosts common settings (stack, website and logging). First we have copy config-example.json as config.json

cd /home/user/CoiniumServ/bin/Debug/config

cp config-example.json config.jsonThen we have to open config.json with your favorite text editor (gedit, vim, pico etc..) and change it according to our needs. 

As configuration files host their own documentation for all sections & parameters, it's pretty self explanatory.

Per-pool configuration

As CoiniumServ can host multiple pools together, you have to also create per-pool configuration files. You need to create per-pool configuration files in;

/home/user/CoiniumServ/bin/Debug/config/pools

By default, you'll see the following per-pool example files;

• default-example.json
• example.json

As CoiniumServ uses a very flexible configuration sub-system you have two different methods to configure pools.

Advanced per-pool configuration

You can use advanced-example.json as a starting point and configure every specific bits;

cd /home/user/CoiniumServ/bin/Debug/config/pools

cp advanced-example.json your-pool.json

advanced-example.json hosts every available configuration option and you can fine them based on your needs. Yet again per-pool configuration files also host their own documentation for all sections & parameters and it's pretty self explanatory.

Default per-pool configuration

While loading per-pool configuration files, CoiniumServ will merge them with the default.json if it does exist, basically allowing you to put your common settings and then only change the required parameters in your per-pool configuration files.

Configure common settings in default.json

Copy default-example.json as default.json and put in common settings for all your pools.

cd /home/user/CoiniumServ/bin/Debug/config/pools

cp default-example.json default.json

Create per-pool configuration files

Once we have default.json in-place, we can create per-pool configuration files based on example.json.

cd /home/user/CoiniumServ/bin/Debug/config/pools

cp example.json your-pool.json

This allow us easier configuration of multiple pools. As an example, we can configure the common stratum parameters in default.json which will apply to all per-pool configuration files;

"stratum": {

    "bind": "0.0.0.0",

    "diff": 16,

    "vardiff": {

        "minDiff": 8,

        "maxDiff": 512,

        "targetTime": 15,

        "retargetTime": 90,

        "variancePercent": 30

    }

}

Now we can simply setup a few more parameters in our per-pool configuration file;

"stratum": {

    "enabled": true,

    "port": 3333,

    "vardiff": {

        "enabled": true

    }

}

Which will be simply merged by as;

"stratum": {

    "enabled": true,

    "bind": "0.0.0.0",

    "port": 3333,

    "diff": 16,

    "vardiff": {

        "enabled": true,

        "minDiff": 8,

        "maxDiff": 512,

        "targetTime": 15,

        "retargetTime": 90,

        "variancePercent": 30

    }

}

Sample step-by-step pool configuration

Requirements

• Coin daemon (find the coin's repo and build latest version from source)
• For hybrid storage moge redis v2.6+ & mysql
• For MPOS compatibility mode: MPOS & mysql

Setup coin daemon

Follow the build instructions for your coin daemon. Through out the guide we'll be using litecoin as our sample coin.
Grab the coin daemon sources & compile;

git clone https://github.com/litecoin-project/litecoin.git

cd litecoin\src

make -f makefile.unix USE_UPNP=0

strip litecoind

Create configuration file for the coin (litecoin.conf) in coin's data folder;

daemon=1

rpcuser=user

rpcpassword=password

rpcport=9333

By default it should be in these locations;

• Windows, appdata/roaming/Litecoin/litecoin.conf
• Linux, ~/.litecoin/litecoin.conf
• MacOS, ~/Library/Application Support/Litecoin/litecoin.conf

Run the coin daemon & let it sync with network. For more information check this guide.

Setup coin config

Make sure a corresponding coin.json file exist in;

cd /home/user/CoiniumServ/bin/Debug/config/coins

Here is the example litecoin.json file;

{

    "name": "Litecoin",

    "symbol": "LTC",

    "algorithm": "scrypt",

    "blockExplorer": "http://block-explorer.com",

    "peerMagic": "fbc0b6db",

    "peerMagicTestnet": "fcc1b7dc"

}

Create per-pool configuration file

Create litecoin.json and edit required parameters;

cd /home/user/CoiniumServ/bin/Debug/config/pools

cp example.json litecoin.json

Coin section

Coin section should point to our coin configuration file;

"coin": "litecoin.json",

Daemon section

Configure daemon rpc connection settings;

"daemon": {

        "host": "127.0.0.1",

        "port": 9333,

        "username": "user",

        "password": "password"

    },

Wallet section

You have to create a central wallet address for your pool which mined coins will arrive and then paid to miners from.

litecoind getaccountaddres ""

Then you have to put the generated address in your per-pool configuration file;

 "wallet" : {

        "address":  "n3Mvrshbf4fMoHzWZkDVbhhx4BLZCcU9oY"

    },

Rewards section

Rewards section allows you to configure operational fees for the pool. Basically you can define an unlimited amount of recipients and percentage.
In the following example, myxWybbhUkGzGF7yaf2QVNx3hh3HWTya5t address will recieve %1 of the all coins mined by our pool as operational fee.

"rewards":  [

        {"myxWybbhUkGzGF7yaf2QVNx3hh3HWTya5t": 1} 

    ],

You can also setup a tiny percentage here to donate the CoiniumServ project automatically. For instructions check here.

Payment processor section

CoiniumServ implements it's own payment-processor though it's optional. If you are using mpos compatibility layer, you would like to disable payments and let MPOS handle it. Otherwise it's a good idea to enable payment-processor in order to pay the miners.

"payments": {

    "enabled": true,

    "interval": 60,

    "minimum": 0.01

},

Stratum server section

You have to configure the stratum service to let CoiniumServ listen for stratum-protocol based miners and assign a unique port for your all pools. You can also enable or disable variable-difficulty (vardiff) support here.

"stratum": {

        "enabled": true,

        "bind": "0.0.0.0",

        "port": 3333,

        "diff": 16,

        "vardiff": {

            "enabled": true,

            "minDiff": 8,

            "maxDiff": 512,

            "targetTime": 15,

            "retargetTime": 90,

            "variancePercent": 30

        }

},

Storage section

CoiniumServ supports multiple-storage layers; hybrid (redis+mysql), MPOS (mysql-only). You have to put in connection settings for the storage layer you selected here and enable it;

"storage": {

    "hybrid": {

        "enabled": false,

        "redis": {

            "host": "127.0.0.1",

            "port": 6379,

            "password": "",

            "databaseId": 0

        },

        "mysql": {

            "host": "127.0.0.1",

            "port": 3306,

            "user": "username",

            "password": "password",

            "database": "db-name"

        }

    },

    "mpos": {

        "enabled": false,

        "mysql": {

            "host": "127.0.0.1",

            "port": 3306,

            "user": "username",

            "password": "password",

            "database": "db-name"

        }

    }

},  

Note that per-pool configuration files host few more sections & settings which are already documented within the sample file itself.

Running the server

Once you have changed the settings for your needs, you are basically ready to run the server.

cd /home/user/CoiniumServ/bin/Debug/

./CoiniumServ

If your configuration files are all okay, the CoiniumServ should be running and start serving the miners. If any problems exist with your configuration file, it'll be complaining about them and require you to fix them.

Running in background

If you want to run CoiniumServ as service on Linux, which means it will be run in background and even you close terminal, use mono-service (from package mono-4.0-service) command:

mono-service CoiniumServ.exe

Troubleshooting

In case of any problems & errors, first make sure that your json configuration files are valid. If you still can't fix the problem, you can get support by methods listed here.

Donation

You are more then welcome to help the project by donating.

Stack Configuration

Stack configuration hosts the settings for your pool stack.

    "stack": {

        "name": "CoiniumServ.com",

        "nodes": [

            {

                "location": "eu",

                "address": "127.0.0.1",

                "default": true

            }

        ]

    }

• name: Name of the pool stack, that will be rendered over various places in your frontend.

nodes

Contains the list of your stratum server nodes over different geographic locations.

• location: Set here the geographic location of your server. Make sure to use the two-letter country code as web front-end will be rendering a flag icon using it.
• address: ip/domain of the server hosting the node.
• default: set this true if you want to set this node as the default one in the stack.

Statistics Configuration

Contains the statistics configuration settings which are used by the web front-end.

"statistics": {

        "updateInterval": 60,

        "hashrateWindow": 300

    }

• updateInterval: Update interval in seconds for updating settings.
• hashrateWindow: How many seconds worth of shares should be included in to calculate hashrate data.

Website Configuration

Settings for embedded web-server and front-end

    "website": {

        "enabled": true,

        "bind": "",

        "port": 80,

        "template": "default",

        "feed": "",

        "backend": {

            "metrics": {

                "enabled": false

            }

        }

    }

• enabled: Is the embedded web-server enabled?
• bind: Interface that embedded web-server will bind. Leave this empty to let it bind on all available interfaces.
• port: Port that embedded web-server listen for http connections.
• template: Name of the template that will be used. It should exist in bin/Release/web.
• feed: Url of the RSS feed that will be used for news.

Backend settings

If enabled, backend will available for pool administrator's use.

Metrics

Settings for metrics interface which is only enabled within debug mode.

• enabled: If enabled, a metrics interface for performance measures will be available over /metrics page. Should be only used for development & debugging purposes.

Logging Configuration

Contains settings for logging subsystem.

{

    "root": "logs",

    "targets": [

        {

            "enabled": true,

            "type": "file",

            "filename": "server.log",

            "rolling": false,

            "level": "information"

        },

        {

            "enabled": true,

            "type": "file",

            "filename": "debug.log",

            "rolling": false,

            "level": "verbose"

        },

        {

            "enabled": false,

            "type": "packet",

            "filename": "packet.log",

            "rolling": false,

            "level": "verbose"

        }

    ]

}

• root: Root folder name that the logs will be put in.

Targets

You can add here log targets with different settings.

• enabled: Is the target enabled?
• type: Type of the target.
• file: Plain file log.
• packet: Specially formatted file that logs network packets for debugging purposes.
• filename: Name of the file.
• rolling: Enable this true to create files for each day.
• level: Minimum log level the target will emit.

Coins

Here is a list of coins that are known to be working;

SHA256

• Acoin
• AmKoin
• AsicCoin
• AurumCoin
• BancorCoin
• BattleCoin
• BDSM
• BetaCoin
• BigBullion
• BitCentavo
• BitRaam
• ChocoCoin
• Continuum
• CrownCoin
• DogeBlackCoin
• Fetish
• FireFlyCoin
• FreiCoin
• GamerHolicCoin
• HamRadioCoin
• Peercoin
• PeerCoinDark
• TitCoin
• TerraCoin
• VikingCoin

Scrypt

• Catcoin
• Earthcoin
• Lottocoin
• Noblecoin

Top of Form

Bottom of Form

CoiniumServ/src/CoiniumServ/config/coins/

Latest commit e4f1350 on Mar 7, 2015 daygle Correct Wrong Symbol For ZET

	..
	21coin.json	Fixed more coin configs.	2 years ago
	365coin.json	Fixed more coin configs.	2 years ago
	README.md	Re-structured coin config options section.	2 years ago
	acoin.json	Added Acoin and some of the missing Coin icons	2 years ago
	alphacoin.json	Fixed more coin configs.	2 years ago
	anoncoin.json	Fixed more coin configs.	2 years ago
	bitcoin.json	Fixed more coin configs.	2 years ago
	bitcoindark.json	Added options, blockExplorer and extra sections support to ICoinConfi…	2 years ago
	bottlecaps.json	Added options, blockExplorer and extra sections support to ICoinConfi…	2 years ago
	cannabiscoin.json	Add CannabisCoin	2 years ago
	casinocoin.json	Fixed more coin configs.	2 years ago
	catcoin.json	Fixed more coin configs.	2 years ago
	continuumcoin.json	Fixed more coin configs.	2 years ago
	copperlark.json	Fixed more coin configs.	2 years ago
	cryptogenicbullion.json	Fixed more coin configs.	2 years ago
	darkcoin.json	Fixed more coin configs.	2 years ago
	devcoin.json	Fixed more coin configs.	2 years ago
	digibyte.json	Fixed more coin configs.	2 years ago
	dogeblackcoin.json	Update dogeblackcoin.json	2 years ago
	dogecoin.json	Fixed more coin configs.	2 years ago
	earthcoin.json	/block page now shows txId in payments table.	2 years ago
	einsteinium.json	Fixed more coin configs.	2 years ago
	elephantcoin.json	Fixed more coin configs.	2 years ago
	emerald.json	Fixed more coin configs.	2 years ago
	execoin.json	Fixed more coin configs.	2 years ago
	fastcoin.json	Fixed more coin configs.	2 years ago
	feathercoin.json	Fixed more coin configs.	2 years ago
	fedoracoin.json	Fixed more coin configs.	2 years ago
	florincoin.json	Re-structured coin config options section.	2 years ago
	fluttercoin.json	Re-structured coin config options section.	2 years ago
	franko.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	freicoin.json	Fixed more coin configs.	2 years ago
	gamerscoin.json	added Gamerscoin + gmc icon	2 years ago
	globalboost.json	Fixed more coin configs.	2 years ago
	globalcoin.json	Fixed more coin configs.	2 years ago
	globaldenomination.json	Fixed more coin configs.	2 years ago
	grandcoin.json	Re-structured coin config options section.	2 years ago
	gridcoin.json	fixed gridcoin.json	2 years ago
	groestlcoin.json	Fixed more coin configs.	2 years ago
	hamradiocoin.json	Create hamradiocoin.json	2 years ago
	hirocoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	hobonickels.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	infinitecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	internetcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	ixcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	joulecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	kittehcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	litecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	lottocoin.json	Re-structured coin config options section.	2 years ago
	luckycoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	maxcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	mazacoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	mintcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	monacoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	mooncoin.json	added noblecoin,mooncoin and used coin definitons	2 years ago
	myriadcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	namecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	netcoin.json	Re-structured coin config options section.	2 years ago
	noblecoin.json	added noblecoin,mooncoin and used coin definitons	2 years ago
	octocoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	peercoin.json	Re-structured coin config options section.	2 years ago
	peercoindark.json	Update peercoindark.json	2 years ago
	phoenixcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	potcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	rubycoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	saffroncoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	sexcoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	skeincoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	spartancoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	stablecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	tekcoin.json	Re-structured coin config options section.	2 years ago
	terracoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	ultimatecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	ultracoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	unobtanium.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	usde.json	added noblecoin,mooncoin and used coin definitons	2 years ago
	vertcoin.json	Started implementing scrypt-n support.	2 years ago
	viacoin.json	coin config updates	3 years ago
	wearesatoshi.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	whitecoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	yacoin.json	added coin-validator script contrib/tools/json-validate.sh	2 years ago
	zetacoin.json	Correct Wrong Symbol For ZET	2 years ago

README.md

Coin definition file format

Json files in this folder are used for defining coin properties so, CoiniumServ can use them. If you can't find an existing file for a coin, make sure too here to get a sample config.

Sample file;

{

    "name": "Litecoin",

    "symbol": "LTC",

    "algorithm": "scrypt",

    "site": "https://litecoin.org/",

    "blockExplorer": {

        "block": "http://block-explorer.com/block/",

        "tx": "http://block-explorer.com/tx/",

        "address": "http://block-explorer.com/address/"

    },

    "options": {

        "isProofOfStakeHybrid": false,

        "blockTemplateModeRequired": false,

        "useDefaultAccount": false,

        "txMessageSupported": false        

    },

    "node": {

        "magic": "fbc0b6db",

        "testnetMagic": "fcc1b7dc"

    },

    "extra": {

    }

}

Fields;

• name: name of the coin
• symbol: symbol of the coin
• algorithm: algorithm used by the coin
• site: coins official site

blockExplorer

• block: URL that block hash will be appended.
• tx: URL that x will be appended.
• address: URL that address will be appended.

options

Settings that manipulate the internal working of server based on coin requirements.

• isProofOfStakeHybrid: Is the coin pow+pos hybrid? Default: false.
• blockTemplateModeRequired: Peercoin variants need a "mode" parameter to be set in in getblocktemplate, so we need to set this true for them. Default: false.
• useDefaultAccount: Needed to set true for Peercoin variants as they always send the coins for new blocks to default account. Default: false.
• txMessageSupported: Does the coin use transaction messages? False by default.

node options

Not in use yet, will be used once embedded daemon-node is developed which will be able to check for block notifications

• magic: Coin's magic string.
• testnetMagic: Magic string for Testnet.

extra

Any extra options that will be handled to algorithm itself.

daemons.json

daemons.json contains configuration for extra daemon connections that can be used by auto-exchange module - which is still not in use.

Basically you can add extra payment daemons so that auto-exchange module can pay in a specific coin even if you don't run a pool for it.

Coin configuration

Contains the configuration for the coin.

"coin": "litecoin.json"

• coin: name of the coin configuration while which should exist in /config/coins/.

Daemon configuration

Contains the settings for pool's daemon connection.

    "daemon": {

        "host": "127.0.0.1",

        "port": 9333,

        "username": "user",

        "password": "password",

        "timeout": 5

    }

• host: ip/hostname of daemon.
• port: the port coin daemon is listening on.
• username: username for rpc connection.
• password: password for rpc connection.
• timeout: timeout for rpc requests.

Meta configuration

Contains meta information about the pool.

    "meta": {

        "motd": "Welcome to CoiniumServ pool, enjoy your stay! - http://www.coiniumserv.com",

        "txMessage": "http://www.coiniumserv.com/"

     }

• motd: message of the day sent to connected miners.
• txMessage: message to be included used within generation transactions.

Wallet configuration

Contains the address of the pool's central wallet.

    "wallet" : {

        "address":  "n3Mvrshbf4fMoHzWZkDVbhhx4BLZCcU9oY"

    }

• address: rewarded coins for mined blocks will arrive this address.

Rewards configuration

Contains the static rewards for found blocks like pool fees.

    "rewards":  [

        {"myxWybbhUkGzGF7yaf2QVNx3hh3HWTya5t": 1} 

    ]

• rewards: list of addresses that gets a percentage from each mined block (ie, pool fee.)

Payment Processor configuration

Contains the configuration for payment processor. Note: DO NOT enable payment processor when using mpos-storage layer.

    "payments": {

        "enabled": true,

        "interval": 60,

        "minimum": 0.01

    }

• enabled: set this true to let CoiniumServ handle the payments, false if you would like some other software like mpos to handle them.
• interval: interval in seconds that payment-processor will be running.
• minimum: minimum amount of coins before a miner is eligable for getting a payment.

Miner configuration

Cointans miner specific settings.

    "miner":  {

        "validateUsername": true,

        "timeout": 300

    }

• validateUsername: set true to validate miner usernames as an addresses against the coin daemon.
• timeout: timeout in seconds to disconnect miners that did not submit any shares for the period.

Job Manager configuration

Contains settings for the job-manager.

    "job":  {

        "blockRefreshInterval": 1000,

        "rebroadcastTimeout": 55        

    }

• blockRefresh: timeout in miliseconds to poll coin daemon for a new block.
• rebroadcast: if now new blocks are found in this many seconds, a new job will be created and broadcasted.

Stratum Server configuration

Contains the settings for stratum server.

"stratum": {

    "enabled": true,

    "bind": "0.0.0.0",

    "port": 3333,

    "diff": 16,

    "vardiff": {

        "enabled": true,

        "minDiff": 8,

        "maxDiff": 512,

        "targetTime": 15,

        "retargetTime": 90,

        "variancePercent": 30

    }

}

Stratum

• enabled: set this true to enable stratum server.
• bind: interface to bind stratum server.
• port: port to listen for stratum connections.
• diff: default difficulty assigned to newly connected miners.

Vardiff

• enabled: set this true to enable variable-difficulty support.
• minDiff: minimum difficulty that can be assigned to miners.
• maxDiff: maximum difficulty that can be assigned to miners.
• targetTime: try to get a single share per this many seconds from miner.
• retargetTime: retarget a miners difficulty ever this many seconds.
• variancePercent: allow difficulty for a miner to vary this percent without retargeting.

Ban configuration

Contains the settings for ban manager that can ban miners that submits invalid shares to reduce system / network load.

    "banning": {

        "enabled": true,

        "duration": 600,

        "invalidPercent": 50,

        "checkThreshold": 100,

        "purgeInterval": 300

    }

• enabled: set this true to enable banning support.
• duration: duration of ban when a miner gets flagged for so.
• invalidPercent: percentage of invalid shares to trigger a ban.
• checkThreshold: number of shares required before a miner's shares are considered for a ban.purgeInterval: purge
• interval in seconds that bans are checked to see if they are expired.

Storage configuration

Contains the settings for storage settings.

"storage": {

    "hybrid": {

        "enabled": false,

        "redis": {

            "host": "127.0.0.1",

            "port": 6379,

            "password": "",

            "databaseId": 0

        },

        "mysql": {

            "host": "127.0.0.1",

            "port": 3306,

            "user": "username",

            "password": "password",

            "database": "db-name"

        }

    },

    "mpos": {

        "enabled": false,

        "mysql": {

            "host": "127.0.0.1",

            "port": 3306,

            "user": "username",

            "password": "password",

            "database": "db-name"

        }

    }

}

Hybrid Storage layer

Settings for hybrid storage layer that holds both redis and mysql connection information.

    "hybrid": {

        "enabled": false,

        "redis": {

            "host": "127.0.0.1",

            "port": 6379,

            "password": "",

            "databaseId": 0

        },

        "mysql": {

            "host": "127.0.0.1",

            "port": 3306,

            "user": "username",

            "password": "password",

            "database": "db-name"

        }

    }

Redis configuration

• host: redis host.
• port: redis port.
• password: set the password if your redis installation requires one.
• databaseId: redis database instance id (optional)

MySQL configuration

• host: database host.
• port: database port.
• username: username for connecting the database.
• password: password for connecting the database.
• database: database name.

Daemons Configuration

Contains extra daemon connections as an array.

    "daemons": [

        {

            "enabled": false,  

            "coin": "litecoin.json",

            "daemon": {

                "host": "127.0.0.1",

                "port": 9333,

                "username": "user",

                "password": "password",

                "timeout": 5

            }

        }

    ]

• enabled: Is the connection enabled?
• coin: name of the coin configuration file that should exist in config/coins/.
• host: ip/hostname of coin-daemon.
• port: the port coin daemon is listening on.
• username: username for rpc connection.
• password: password for rpc connection.
• timeout: timeout for rpc requests.

Coin definition file format

Json files in this folder are used for defining coin properties so, CoiniumServ can use them. If you can't find an existing file for a coin, make sure too here to get a sample config.
Sample file;

{

    "name": "Litecoin",

    "symbol": "LTC",

    "algorithm": "scrypt",

    "site": "https://litecoin.org/",

    "blockExplorer": {

        "block": "http://block-explorer.com/block/",

        "tx": "http://block-explorer.com/tx/",

        "address": "http://block-explorer.com/address/"

    },

    "options": {

        "isProofOfStakeHybrid": false,

        "blockTemplateModeRequired": false,

        "useDefaultAccount": false,

        "txMessageSupported": false         

    },

    "node": {

        "magic": "fbc0b6db",

        "testnetMagic": "fcc1b7dc"

    },

    "extra": {

    }

}

Fields;

• name: name of the coin
• symbol: symbol of the coin
• algorithm: algorithm used by the coin
• site: coins official site

blockExplorer

• block: URL that block hash will be appended.
• tx: URL that x will be appended.
• address: URL that address will be appended.

options
Settings that manipulate the internal working of server based on coin requirements.

• isProofOfStakeHybrid: Is the coin pow+pos hybrid? Default: false.
• blockTemplateModeRequired: Peercoin variants need a "mode" parameter to be set in in getblocktemplate, so we need to set this true for them. Default: false.
• useDefaultAccount: Needed to set true for Peercoin variants as they always send the coins for new blocks to default account. Default: false.
• txMessageSupported: Does the coin use transaction messages? False by default.

node options
Not in use yet, will be used once embedded daemon-node is developed which will be able to check for block notifications

• magic: Coin's magic string.
• testnetMagic: Magic string for Testnet.

extra
Any extra options that will be handled to algorithm itself.

 

default.json

• default.json contains the common configuration for the pools. You have to first copy default-example.json as default.json. Then you can put common settings for your pools on default.json as while loading pool.json configuration files, default.json values will be merged.
• Sample
• {
•     "daemon": {
•         "host": "127.0.0.1",
•         "timeout": 5
•     },
•     "meta": {
•         "motd": "Welcome to CoiniumServ pool, enjoy your stay! - http://www.coiniumserv.com",
•         "txMessage": "http://www.coiniumserv.com/"
•     },
•     "payments": {
•         "interval": 60,
•         "minimum": 0.01
•     },
•     "miner": {
•         "validateUsername": true,
•         "timeout": 300
•     },
•     "job": {
•         "blockRefreshInterval": 1000,
•         "rebroadcastTimeout": 55
•     },
•     "stratum": {
•         "bind": "0.0.0.0",
•         "diff": 16,
•         "vardiff": {
•             "minDiff": 8,
•             "maxDiff": 512,
•             "targetTime": 15,
•             "retargetTime": 90,
•             "variancePercent": 30
•         }
•     },
•     "banning": {
•         "duration": 600,
•         "invalidPercent": 50,
•         "checkThreshold": 100,
•         "purgeInterval": 300
•     },
•     "storage": {
•         "hybrid": {
•             "redis": {
•                 "host": "127.0.0.1",
•                 "port": 6379,
•                 "password": "",
•                 "databaseId": 0
•             },
•             "mysql": {
•                 "host": "127.0.0.1",
•                 "port": 3306,
•                 "user": "username",
•                 "password": "password"
•             }
•         },
•         "mpos": {
•             "mysql": {
•                 "host": "127.0.0.1",
•                 "port": 3306,
•                 "user": "username",
•                 "password": "password"
•             }
•         }
•     }
• }

Donation

Hüseyin Uslu edited this page on Jul 25, 2014 · 1 revision

You can manually donate the following address to help development of the project;

• BTC: 18qqrtR4xHujLKf9oqiCsjmwmH5vGpch4D
• LTC: LMXfRb3w8cMUBfqZb6RUkFTPaT6vbRozPa
• DOGE: DM8FW8REMHj3P4xtcMWDn33ccjikCWJnQr
• RDD: Rb9kcLs96VDHTmiXVjcWC2RBsfCJ73UQyr

Additionally when configuring a pool, you can setup an automatically donatied percent to project itself. You can achieve this by adding an entry to rewards section in pool configuration file.

Example bitcoin configuration

"rewards":  [

        {"18SAmNFjHfZmf3T3Re4nfztvYGBC42RTAb": 1},   // %1 goes to pool-operator

        {"18qqrtR4xHujLKf9oqiCsjmwmH5vGpch4D": 0.5}, // %0.5 goes to CoiniumServ project as donation

    ],

Example litecoin configuration

"rewards":  [

        {"LbZLhgjvkiowsfq3LfxuPKFjTAUTY7BvHj": 1},   // %1 goes to pool-operator

        {"LMXfRb3w8cMUBfqZb6RUkFTPaT6vbRozPa": 0.5}, // %0.5 goes to CoiniumServ project as donation

    ],

Example dogecoin configuration

"rewards":  [

        {"DDUJX7toaLx9nwKeHyDwNiMRxcUPR65b3Z": 1},   // %1 goes to pool-operator

        {"DM8FW8REMHj3P4xtcMWDn33ccjikCWJnQr": 0.5}, // %0.5 goes to CoiniumServ project as donation

    ],

If you require a specific coin address for your donations, please let us know so that we can create one so.

Requirements

• mono 3.10.x+
• git

Mono

Follow the instructions over here to install mono on your system.

Getting the sources

Once you have mono installed, you can download the sources using git;

git clone https://github.com/CoiniumServ/CoiniumServ.git

cd CoiniumServ

git submodule init

git submodule update

Building

Then you can compile the sources using;

cd build/release

./build.sh

You can read below the development model we use within the process;

The model is based on http://nvie.com/posts/a-successful-git-branching-model/

Basically we need two core branches;

• master (default branch with stable & tested code)
• develop ( development branch with next-gen code that still needs proper testing)

Feature branches; Our proposal follows http://nvie.com/posts/a-successful-git-branching-model/ and PR's will be named in this format; "feature-FUNCTIONALITY-DESCRIPTION".

A proper PR should be referencing the issue that it fixes. I've also put a basic developer guide here.

Tags Tagging releases will be quite useful.

Milestones The new model will also allow us to utilize the git's milestone's feature, so we can target releases.

The plan

• Utilize the feature-XYZ branching model.
• Setup a new milestone for basic functionality targets
• Merge develop to master once we hit our milestones targets and tag them.
• Continue to follow the model.

With all this branching model a pool operator can just;

• stay in master branch and use the latest stable & tested code
• stay with develop branch and merge the latest upstream changes
• can just merge in a feature-XYZ branch for cutting-edge features & testing.