################################################################
# Includes #
################################################################
### This allows you to include other properties files by including a comma delimited list of filenames.
### The path is relative to the location of THIS properties file.
###
### This may be useful for testing/troubleshooting scenarios allowing you split database config or
### any other block of config to a seperate file for easy changes.
###
### Properties are accumlated and overwritten in order. e.g. if the same property appears in this
### file and in one the include files the include property will take precedence.
### Included properties files can also use the include property. File are processes by walking the tree
### e.g. this file, 1st include file, 1st include file's include file, 2nd include file.
### If you precede the list with a '!' char this will prevent conficts and throw an error if any
### included property overwrites one that is already set. Child properties can also set this flag.
### prefix with '!!' will force the conflicts flag to be inherited and conflict flags in child properties
### will be ignored. You can set the inheritance flag in a child properties file and it will only apply
### to children of that properties file.
#include=props1/debug.properties
################################################################
# Coinbase Donations #
################################################################
### This option will only work if source.local.1.localWorkGeneration=true
### It allows you send a donation as part of the coinbase transaction to the poolserverj developer
### or anyone else. You can send multiple donations to different addresses so if you use
### an open source front end you may want to consider including them in the donation list.
### donationTarget chainName must match the names you've given the chains in merged mining setup.
### Donations on aux chains are only supported if you have applied the getmemorypool patch to your
### aux daemon.
###
### addressUrl is a URL you can point to obtain a current payout address. The returned format
### is simply a json object with a list of keypairs using chainName as key and address as value.
### the string '.testnet' is appended to chain name for testnet addresses. e.g.
### {"bitcoin":"1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq", "namecoin":"NFpgM5Ds3o9GwkqEoW5NnGstc2Lw7rHcYa"}
### defaultAddress is just a standard bitcoin address which will be used if no dynamic address can be found.
###
### Payout amount can be calculated several ways and the calculation method is determined by the payout
### amount format. Examples:
### donationTarget.1.amount=0.15 <-- if you simply put a number this a fixed amount donation in FULL BTC's NOT SATOSHIS.
### donationTarget.1.amount=0.3% <-- appending a '%' will calculate the donation as a percentage of the total block reward including transaction fees
### donationTarget.1.amount=0.4%- <-- appending '%-' will calculate the donation as a percentage of the total block reward excluding transaction fees
### donationTarget.4.amount=20%t <-- appending '%t' will calculate the donation as a percentage of the transaction fees only.
### If for example you wanted to donate a different rate for main block reward and transaction fees you could set up something like this
### to payout 0.3% of block reward and 20% of transaction fees:
###
### donationTarget.1.chainName=bitcoin
### donationTarget.1.defaultAddress=1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
### donationTarget.1.amount=0.3%-
###
### donationTarget.2.chainName=bitcoin
### donationTarget.2.defaultAddress=1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
### donationTarget.2.amount=20%t
################################################################
# General Config #
################################################################
### default false
#testnet=true
### Turns on logging of some additional status messages.
debug=true
### Turn this off if you don't need it. It does consume resources even if you've got a limited set of traceTargets
trace=false
### traceTargets enables tracing on particular event groups. traceTarget 'all' means what it says. Prepare for a big log file.
### Available trace targets are logged by poolserverj on startup. Best to look at that rather look for a list here
### as there will probably be new ones added frequently. Look for a line like:
### Trace activated, available trace targets: [blockmon, worker_stats, worker_cache, longpoll, blockmon_worksource, all]
### You can also prepend a '-' symbol before any trace target to exlude it. If you want to see everything you can set 'all'
### but if you find a particular tracetarget is spamming the log too much you can get rid of it this way.
### comma delimited list
traceTargets=
### whether to log full stack traces on exceptions or just the exception message. If you're asking the developer for
### help on an exception these are very useful.
logStacktraces=true
pidFile=tmp/poolserverj.pid
### Typically only used for stress testing and benchmarking. Sets difficult to
### target that requires only 1-2 hashes to solve a block. This is NOT the same as rewriting difficulty target
### to difficulty 1. You will get MASSES of requests if you turn this on with a GPU miner attached to your pool.
useEasiestDifficulty=false
### Allows you to set alternative proof of work hashing algorithm
### Supported algos are: doublesha256, scrypt
### default: doublesha256
POWalgorithm=doublesha256
### This is for beta testing only, this will be deprecated after confirming valid blocks are always
### pushed up to a local bitcoin daemon. It will force every share submitted by a miner to be submitted
### to the daemon.
forceAllSubmitsUpstream=false
### default: true. Safe restart cause the server to dump it's mappings of work to worker to a file on shutdown
### and reload them on next startup. This is only relevant if the server is going to be restarted within a couple
### of minutes. If the server is started any later than that the map will be discarded after
### it is reloaded.
### The file is located at tmp/workmap-.bin
enableSafeRestart=true
### currently only HTTP JSON-RPC supported
listen.http.json-rpc.port=8999
listen.http.json-rpc.path=/
################################
# Longpolling #
################################
### Please also see long polling options under Work Sources entries
listen.longpoll.enable=true
### listen.longpoll.http.json-rpc.port=8999 ##deprecated now parsed from listen.longpoll.http.json-rpc.url
### pass the full url not just the path
### IMPORTANT! longpoll path MUST END WITH A TRAILING SLASH. If it does not it will be added. Java servlets are fussy
### about URLs conforming to spec.
### Also note that some miners do not handle the X-Long-Polling header properly (e.g. Phoenix). It is supposed
### to be able to handle a full URL including port but Phoenix 1.50 for example will poll the new url on the main port even
### if a different port is specified so for this reason we recommend using the same port as the main listener.
listen.longpoll.http.json-rpc.url=http://localhost:8999/LP
### in seconds
listen.longpoll.http.json-rpc.timeout=600
### If you are having trouble with longpoll spam you can set a limit on LP connections per worker.
### connections in excess will not be refused, they will be held open and closed at the end of the block to prevent
### retry spam.
### The default limit will be applied after the worker is retrieved from the database but only IF it's value when it returns
### = 0 or -1. This allows you to set it from a database column if you want per worker limits.
### 0 or -1 = no limit
listen.longpoll.defaultMaxLPConnectionsPerWorker = -1
#################################
# Native Longpolling #
#################################
### See the native longpolling section under Upstream Sources for more detail.
native.longpoll.port=8950
### timeout for remote host to send LP string before closing the socket.
native.longpoll.timeout=2000
################################
# DDos Resilience #
################################
### There are two options for DDos resilience, both provide significant protection against low level DDoS attacks.
### They can be enabled individually or together. Each will add a slight overhead to request processing so if you
### already have DDoS protection consider disabling.
### Note that this protection is at the webserver level. If you are under an attack large enough to clag your
### ip stack then the requests may not even be getting this far. Consider using a more low level type protection if
### DDoS is a real threat for your pool.
### QoS Filter prioritizes incoming requests for authenticated users. It also grants additional priority to those
### users that have submitted valid proof of work in the current or previous blocks. This provides some level of
### protection against a flood of useless requests.
enableQoS=true
QoSMaxRequestsToServiceConcurrently=55
### DoSFilter provides rate limiting and throttling on a per connection (ip + port) basis.
### Adds an additional level of DoS protection against a single client DoS attacks but QoS Filter will probably
### be more effective against DDoS.
### Update: Real world testing has shown the DoS Filter is more trouble than it's worth. QoS is a much better option.
enableDoSFilter=false
DoSFilterMaxRequestsPerSecondBeforeThrottle=10
################################
# Notifications #
################################
### If set PoolServerJ will send a notification on block change so you know when to process shares
### without needing to constantly poll the database.
### Currently only method support is httpget - if you can suggest any other push type methods let us know.
### get will be sent with params: ?blockchange=true&blockwon=&source=
### This url is not part of PoolServerJ. You can implement a PHP page for example that will react to the call
### and do your payment processing cycle.
#notify.blockchange.method=httpget
### highly recommend this is not a publicly accessible URL or that you at least check the request is from localhost
### or you could be open to a DoS by forcing constant payout processing.
#notify.blockchange.url=http://localhost:10001/notifyblockchange-downstream
### server will probably be flat out for a few seconds after a block change servicing getworks so you may not want
### to be doing huge database queries to process payouts straight away.
### milliseconds - default 5000
notify.blockchange.delay=10000
################################
# Management Interface #
################################
### Allows some calls to be issued to server using HTTP GET requests.
### Recommended you block this port on your firewall as well but it will ignore all requests unless from an address in
### the allowedManagementAddresses property
### current functions supported:
### flushWorker - removes worker from cache, call this if the worker is changed by your frontend.
### e.g. http://localhost:8997/?method=flushWorker&name=myworker
### e.g. http://localhost:8997/?method=shutdown
enableManagementInterface=true
allowShutdownByManagementInterface=true
### MUST be different to both listen.http.json-rpc.port and longpoll port
managementInterfacePort=8997
### Forces mgmt interface to only bind to 127.0.0.1
bindManagementInterfaceOnlyToLocahost=true
### comma delimited for multiple addresses. This doesn't affect interface bindings, it is verification after the request is received.
### If bindManagementInterfaceOnlyToLocahost=true this won't work for any addresses other than localhost.
### If bindManagementInterfaceOnlyToLocahost=false and you only have localhost as an allowed addres external client can still hit the
### interface but will get an unauthorized response.
### Wildcards are not supported.
allowedManagementAddresses=127.0.0.1,10.1.1.10
################################
# Memory Management #
################################
### Sleep interval (in seconds) before checking worker and work caches for expired entries. This may still happen while sleeping as all entries
### are checked for expiry conditions whenever they are retrieved.
flushCacheInterval=20
### In seconds. Period to cache workers in memory to avoid constant hits to the database. You can set this to a long value if you
### use the flushworker call (see allowedManagementAddresses)
### This also caches unknown usernames to protect against a flood of database hits from unregistered workers.
### Note that if this is set to a reasonably long period you pool will be highly resilient to temporary database outages
workerCacheExpiry=3600
### By default entries in the worker cache are only evicted if they aren't looked up for longer than workerCacheExpiry
### This can potentially mean if a worker is updated from your pool front end the cached entry will remain and the update won't take.
### The management interface method 'flushWorker' is provided to ensure the worker cache entry is refreshed in this circumstance and allows
### maximum cache performance. If for some reason you are physically or philosophically unable to use this feature you can use this option
### to use a fixed time eviction strategy. This will ensure worker entries are refreshed at an interval of workerCacheExpiry.
### We don't recommend this strategy hence the silly name which is a jibe at the pool operator who requested it.
### To protect the guilty he shall remain anonymous.
###
### default: false
#useBrokenWorkerCacheEvictionStrategyBecauseImTooLazyToAdjustMyFrontendToUseTheCacheProperly=false
### Enforce case sensitivity when looking up workers in the cache. This does not affect DB lookups.
### If this is set to true you must ensure you worker DB query uses a case sensitive comparison.
### default: false
#caseSensitiveWorkerNames=false
### When work is issued a unique portion is stored internally in a map. This map can grow very large.
### If a worker submits work and it is not in this map an 'unknown-work' response will be issued unless
### the work is in the previous block's map in which case a 'stale-work' will be issued.
### pushpoold has a hardcoded cache timeout of 120 seconds. So it's reasonable to expect that most miners
### will not try to retain work for longer than this period. Shorten it at your peril.
### (seconds)
maxAgeToMapWorkSource=130
################################
# X-Mining-Extensions #
################################
### NOTE: As of v0.4.0rc1 mining extensions are only partially implemented and not functional.
### To understand what the different mining extensions do see https://en.bitcoin.it/wiki/Getwork
### float. Noncerange is calculated based on hashrate reported by the miner. So to ensure
### The range provides enough space that miner doesn't run out of nonces in 1 second we can
### pad the nonce range to allow some headroom.
### basically this number is the approximate number of seconds the noncerange should last for
### before the miner uses up all the nonce space. If rollNTime is enabled then 2 should be
### plenty of headroom. If not then you'll probably want a much bigger number like 120
### so the worker doesn't need to refresh work for 2 minutes.
### set to -1 to disable nonceRange
#nonceRangePaddingFactor=20.0
### This is the period (in seconds) that the miner is allowed to roll the timestamp of the delivered
### work and still have it considered valid when submitted as a share
### THIS MUST BE <= maxAgeToMapWorkSource. If it is not then work entries may be deleted from the work map
### whilst the miner is still working on it and when it does eventually submit it will receive a 'stale'.
### It is recommended to set this a few seconds below maxAgeToMapWorkSource.
### set to -1 to disable rollNTime
#rollNTimeExpire=120
################################################################
# Logging #
################################################################
### Output to logs and to database will be in the same format as pushpool. Use this if you want a drop in replacement for pushpool.
### if false you will get some extra data logged including blocknumber and the name of the work source that provided each share.
### Note: the database definition will be slightly different for non-compatability mode in the shares table:
### time column should be a TIMESTAMP
### our_result and upstream result should be a BOOLEAN or INT(1)
## ensure db.stmt.insertShare is set to the appropriate INSERT statement
usePushPoolCompatibleFormat=false
### if path is relative it will be relative to the directory that the runtime jar file
### windows users use forward slashes or double backslashes i.e.
### C:/pool/log/error.log or C:\\pool\\log\\error.log
#errorLogFile=log/error.log
#stdOutLogFile=log/out.log
### the following two can be commented out if you don't want file logging. Note though that requests are not logged to database
### so this is your only option for if you want to record them.
sharesLogFile=log/client-shares.log
requestsLogFile=log/client-requests.log
################################################################
# Logging Requests #
################################################################
### don't cache requests, flush straight to file.
request.flushToFilesImmedate=false
request.maxRequestsToQueueBeforeCommit=100
### seconds
request.maxRequestAgeBeforeCommit=10
### send requests to stdout
requestsToStdout=false
################################################################
# Logging Shares #
################################################################
### flush new shares straight to file. - database logging will still use caching if enabled.
shares.flushToFilesImmedate=false
### to disable caching and force direct database write set this to 0.
shares.maxEntrysToQueueBeforeCommit=500
### seconds
shares.maxEntryAgeBeforeCommit=10
### send shares to stdout
sharesToStdout=false
################################################################
# Submitting Shares Upstream #
################################################################
### Hardcoded maximum of 10
submit.maxConcurrentSubmitRequests=5
### in milliseconds = max 1000
submit.minIntervalBetweenHttpRequests=0
### max 3
submit.maxSubmitRetryOnConnectionFail=3
################################################################
# Database #
################################################################
################################
# Custom Engines #
################################
### if you want to replace the standard engines for authetication with different implementations
### you can set these options. You must specify the engines using the fully qualified class name
### If specifying a custom engine you provide an engine with specific constructor signature
### as the engine are instantiated by reflection.
### For more information on custom engines and building your own plugins see:
### http://poolserverj.org/documentation/plugin-guide/
### This engine manages the fetching of workers from the database (or whereever else you want to
### store them.
### AnyWorkerFetchEngine is an alternative that does not check the DB, it simply returns a worker
### with the supplied username and password.
### Required Constructor signature: (String[] extraParams)
#db.engine.workerFetch=com.shadworld.poolserver.db.worker.WorkerDBFetchEngine
### This allows some extra config of your custom engine. It is a comma delimited list
### which will be passed to your constructor as an array of strings (String[] extraParams). An empty
### entry in the list i.e. 'param1,,param3' will be passed as an empty string
### If you require non String arguments you must parse these into the appropriate type in
### you constructor. e.g. Integer.parseInt(extraParams[0]);
### Sorry no escape char. If you need to use a delimited list as one of your params you'll need
### to use a different delimiter.
#db.engine.workerFetch.extraParams=param1,,param3
### This engine allows for customised Authentication behaviour. Not really a database engine
### but better to keep them all together.
### An alternative AnyPasswordWorkerAuthenticator is provided that allows any password.
### Required Constructor signature: (WorkerProxy workerProxy, String[] extraParams)
#authenticatorEngine=com.shadworld.poolserver.servlet.auth.WorkerAuthenticator
### @see comments for #db.engine.workerFetch.extraParams property
#authenticatorEngine.extraParams=param1,param2,param3
#authenticatorEngine=com.shadworld.poolserver.servlet.auth.AnyPasswordWorkerAuthenticator
#authenticatorEngine.extraParams=true,false
### This engine handles logging of shares to database (it is separate from file and stdout logging)
### An alternative BlackHoleSharesDBEngine is provided to prevent all DB logging.
### Required Constructor signature: (ShareLogger shareLogger, String tempFilename, String[] extraParams)
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.DefaultPreparedStatementSharesDBFlushEngine
### @see comments for #db.engine.workerFetch.extraParams property
#db.engine.shareLogging.extraParams=param1,param2
### see source code for other available engines
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.bulkload.JavaPipesBulkLoader
#db.engine.shareLogging=com.shadworld.poolserver.db.shares.bulkload.DirectFifoBulkLoader
### Only required for some of the BulkLoader engines that use local fifos or temp files.
### See notes in source of those engines for requirements to use these features.
#db.engine.shareLogging.tempfile=/tmp/mysql/fifo
################################
# Database Connections #
################################
### Shares and Workers operation use two seperate connections internally. By default
### these both use the same set of parameters. If you want to use different connections
### you specify either some or all connection parameters individually.
### The set of parameters that can be set like this are:
### db.engine, db.host, db.port, db.name, db.schema, db.file, db.user, db.password, db.url
### , db.connectionOptions
### To customise a parameter simply add a new property in the following format:
### db.shares.schema=shares_schema or db.worker.schema=worker_schema
###
### The config process will first check for a customised parameter and if not present
### will fall back to the standard parameter i.e. db.schema
### If you only want to change one you can use the standard parameters for all except the
### one that differs.
### mysql ###
db.engine=mysql
db.host=localhost
db.schema=test
db.port=3306
db.user=smart
db.password=smart
### JDBC connection options. This a comma delimited list of = pairs
### these allow you to add arbitrary connection parameters to your database connection.
db.connectionOptions=rewriteBatchedStatements=true
db.column.username=username
db.column.password=password
db.column.id=id
### this column should contain a comma delimited list of ip addresses or hostnames.
### if this property is not set then host validation will be disabled.
db.column.allowHosts=allowed_hosts
###
### Share Logging Query and Column Mapping - ***READ THIS***
###
### db.stmt.insertShare.columnMapping is how you tell poolserverj which data fields appear in what order in
### your SQL statement so it puts the right data in the right fields.
### The format is a comma delimited list. Each entry is two numbers separated by a ':'. The first number is the
### position where that field appears in your sql statement beginning at number 1, *NOT* 0, for the first column. The second number
### is the number from the approriate field in the list below.
### Fields can be excluded simply by leaving them out of the list.
###
### Example: Using the below following query
### INSERT INTO shares (username, reason, our_result, upstream_result) VALUES (?, ?, ?, ?)
### the mapping would look like this:
### db.stmt.insertShare.columnMapping=1:2,2:5,3:3,4:4
###
### Available fields:
###
### 1 - remote_host - TEXT or VARCHAR
### 2 - username - TEXT or VARCHAR
### 3 - our_result = BOOLEAN or INT(1), if pushpoolCompatibility mode: ENUM(Y,N) or TEXT or VARCHAR
### 4 - upstream_result = BOOLEAN or INT(1), if pushpoolCompatibility mode: ENUM(Y,N) or TEXT or VARCHAR
### 5 - reason - TEXT or VARCHAR
### 6 - solution - TEXT or VARCHAR (length 257)
### 7 - time - TIMESTAMP
### 8 - source - TEXT or VARCHAR
### 9 - block_num - INT or TEXT or VARCHAR
### 10 - prev_block_hash - TEXT or VARCHAR(65) - this is just solution.substring(8, 72) - may be useful for indexing
### 11 - useragent TEXT or VARCHAR
###
### 12 - 50 reserved
###
### The following mappings are for partial merged mining results where a submitted data is stale
### for some but not all chains. The field type is the same as for our_result
### Sha256 chains
### 51 - our_result_bitcoin
### 52 - our_result_namecoin
### 53 - our_result_devcoin
### 54 - our_result_ixcoin
### 55 - our_result_i0coin
### 56 - our_result_geistgeld
###
### SCrypt chains
### 151 - our_result_tenebrix
### 152 - our_result_fairbrix
### 153 - our_result_litecoin
###
### If you have more than one local source it is highly recommended to use field 8 (sources) so that when you win a block
### you have a way of tracking which wallet to payout your members from.
###
db.stmt.insertShare=INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, solution, time, source, block_num, our_result_bitcoin, our_result_namecoin, useragent, prev_block_hash,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
db.stmt.insertShare.columnMapping=1:1,2:2,3:3,4:4,5:5,6:6,7:7,8:8,9:9,10:51,11:52,12:11,13:10,14:12,15:13,16:14,17:15,18:16,19:17,20:18,21:19,22:20,23:21,24:22,25:23,26:24,27:25,28:26,29:27
### native example for merged mining with namecoin only as an aux chain - ensure usePushPoolCompatibleFormat=false
#db.stmt.insertShare=INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, solution, time, source, block_num, our_result_bitcoin, our_result_namecoin, useragent, prev_block_hash) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
#db.stmt.insertShare.columnMapping=1:1,2:2,3:3,4:4,5:5,6:6,7:7,8:8,9:9,10:51,11:52,12:11,13:10
### native example for non-merged mining setup with 'solution' field excluded
#db.stmt.insertShare=INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, time, source, block_num, useragent) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
#db.stmt.insertShare.columnMapping=1:1,2:2,3:3,4:4,5:5,6:7,7:8,8:9,9:11
### This is your worker select statement. It may not be used if you have a custom WorkerFetcher engine.
db.stmt.selectWorker=SELECT * FROM pool_worker WHERE username LIKE ?
db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);
### postgresql ###
#db.engine=postgresql
#db.host=localhost
#db.name=psj
#db.schema=poolserverj_native
#db.port=5432
#db.user=ps_test
#db.password=ps_test
### sqlite3 ###
#db.engine=sqlite3
### For windows file naming convention see comments for errorLogFile property
#db.file=sqlite/psj.db
#db.stmt.insertShare=
#db.stmt.selectWorker=SELECT * FROM pool_worker WHERE username LIKE ?
################################################################
# Upstream Sources #
################################################################
###
### These are your sources of work. Local sources are typically bitcoin daemons or WorkMaker internally generated.
###
### You can have more than one of either type of source. For example your bitcoin daemon may be struggling to keep
### up with requests so you can run a 2nd daemon on another machine and use it as a 2nd source to speed up your getwork
### delivery. If you are using local work generaration (WorkMaker) then you probably don't need additional sources.
### WorkMaker is at least 10 times faster than rpc in it's earliest iterations and will like be significantly
### faster after some optimization.
###
### If you do have more than a single source it is recommended
### that you add a 'source' column to your shares table in your database so you can track which source winning blocks
### came from.
###
### To use multiple sources simply use a different numbered prefix for each of the properties.
### i.e. source.local.1.name=local bitcoin daemon1
### source.local.2.name=local bitcoin daemon2
### Make sure you do this for each of the properties for that source and make sure you give them all unique names
### for tracking.
### Make sure you read the comment for the source.local.1.weighting property, this explains how work is divided among
### sources.
#################################################
# Local Source 1 #
#################################################
### this just saves you commenting out every parameter if you want to disable a source.
#source.local.1.disabled=true
### This should be unique. If you are not using pushpool compatability mode for logging then this can be added
### to share logs so you can track where the shares are going.
source.local.1.name=bitcoind-mm
### If local work generation is true poolserverj will use it's own internal work generation algorithm.
### This is far more efficient that using JSON-RPC (at least 10x).
### The rpc details are still needed as the bitcoin daemon is used to obtain metadata and also for block change monitoring.
### Note that this requires a bitcoin daemon with the getmemorypool patch. This is part of the standard bitcoin client
### as of v0.5
source.local.1.localWorkGeneration=true
### a valid bitcoin address to receive the payout from the coinbase transaction.
### this default address is a testnet address and will cause the server to shutdown
### if you use it on production. Just to make sure you don't forget!
source.local.1.localWorkGeneration.payoutAddress=1GLSL8GxBU5LY32mZYNg9kF3vXzUs9Supt
### If a new transaction arrives with a large fee you may want to trigger an early longpoll
### to get miners to include it. This is the threshold since the last longpoll that will
### cause a longpoll to trigger (in whole bitcoins).
### @not implemented yet
source.local.1.localWorkGeneration.txFeeChangeLongpollTrigger=0.1
### a short UTF-8 encoded message string that can be added to the end of the coinbase sig script.
### This is hard limited to 20 bytes and will be truncated if it is longer.
source.local.1.localWorkGeneration.coinbaseMessage=hi from poolserverj
### url including port of your bitcoin daemon i.e. http://localhost:8332/
source.local.1.url=http://localhost:8332/
source.local.1.p2p.hostport=localhost:8373
### json-rpc username - for standard bitcoind this is set in bitcoin.conf (rpcuser)
source.local.1.username=smart
### json-rpc password - for standard bitcoind this is set in bitcoin.conf (rpcpassword)
source.local.1.password=smart6202H9rIC8EItrVd3u3Z
#######################
# Merged Mining #
#######################
### READ THIS - chain names used in various parts of poolserverj config are not arbitrary.
### They are all lowecase and are typically the full name of the chain.
### e.g. Bitcoin is 'bitcoin' not 'btc'. If you use variation the server will throw
### and error on startup.
### valid chain names as at v0.4.0rc1 are:
### "bitcoin", "namecoin", "devcoin", "ixcoin", "i0coin", "geistgeld", "tenebrix", "fairbrix", "litecoin"
### This parameter should be set EVEN if you are not using merged mining.
source.local.1.merged.parentchain=bitcoin
### To activate merged mining you need to declare each aux chain.
### This is a comma delimited list of all the chains for which you will define parameters
### Each of the auxchain parameters must then use that name as part of the prefix.
### e.g. using namecoin as an example
### source.local.1.merge.chains=namecoin
### Now each parameter for that chain must be prefixed with:
### source.local.1.merge.namecoin.param=
### ONLY include aux chains in this list.
source.local.1.merged.chains=namecoin
### now to define parameters for our named chain 'namecoin'
source.local.1.merged.namecoin.chainid=1
### you MUST have a getmemorypool enabled aux daemon to use
### this on the aux chain.
#source.local.1.merged.namecoin.localCoinbasing=true
source.local.1.merged.namecoin.payoutAddress=Mz3Qs4eDoE7USV8sjnCf8aATeHCJAtM5Zp
source.local.1.merged.namecoin.url=http://localhost:8331/
source.local.1.merged.namecoin.username=smart
source.local.1.merged.namecoin.password=smart
### @see source.local.1.localWorkGeneration.txFeeChangeLongpollTrigger
### @not implemented yet
source.local.1.merged.namecoin.txFeeChangeLongpollTrigger=0.1
#######################
# /Merged Mining #
#######################
### Weighting determines how many requests will come from each source.
### The approximate percentage of requests serviced but this source is weighting / sum(all weightings) * 100.
### e.g. if you have source.local.1.weighting=25 and source.remote.1.weighting=75, 25% of requests will be serviced
### by source.local.1
source.local.1.weighting=5
### this is per source, so don't go overboard if you've got multiple sources or you might clog up your machine with masses of concurrent threads
### with a local client testing has shown 10 is a good number. More or Less reduced performance. For high latency connection you may want to try higher.
### BUT if the source supports multiget mode you probably don't want this much higher than 3.
### If you are using WorkMaker generation this is the number of concurrent threads dedicated to generating work.
### We recommend about 5 threads / virtual core to achieve close to full cpu saturation during getwork cycles.
source.local.1.maxConcurrentDownloadRequests=50
### no need to go too high since submits are far more rare than requests.
source.local.1.maxConcurrentUpstreamSubmits=3
### in seconds - age is the time between now and when the work was fetched from the source.
source.local.1.maxWorkAgeToFlush=30
### in milliseconds = max 1000
source.local.1.minIntervalBetweenHttpRequests=0
### in milliseconds = max 1000 - alternate value used immediately after a block change
source.local.1.minIntervalBetweenHttpRequestsWhenFrantic=0
### max works to cache. Server will continually poll upstream until the cache has reached this limit.
### as soon as it drops under this number it will start polling again to keep the cache full.
### work can be removed from cache either by delivering to a client or by sitting there for longer than
### maxWorkAgeToFlush
source.local.1.maxCacheSize=500
### maximum time in milliseconds to wait for the cache to return work before giving up and returning an error result.
source.local.1.cacheWaitTimeout=3000
#################################
# Block Change Monitoring #
#################################
### This is the method used to determine when the work source has changed to a new block.
### currently poll mode is the only implementation (native coming soon). Poll mode checks
### each incoming work for a change of prev_block_hash. If no work has come in for 'maxPollInterval'
### milliseconds a getblocknumber request is issued instead.
### native monitoring is coming soon...
### It is recommended if using WorkMaker to poll more frequently as the daemon is only contacted
### about once/sec to get new transactions.
###
### valid values: poll, native_longpoll
source.local.1.blockmonitor.mode=poll
source.local.1.blockmonitor.maxPollInterval=100
#################################
# Native Longpolling #
#################################
### Native longpolling requires considerable extra configuration but can gain some valuable extra
### milliseconds between when a new block comes in and when your miners start working on fresh work.
### Please see http://poolserverj.org/documentation/configuring-native-longpolling/ for details.
source.local.1.longpoll.native.enable=false
### Once you are sure native longpolling is working correctly you can disable the fallback verification.
### Verifications involve a JSON-RPC call to getblocknumber before firing the blockChange event. So this
### will speed up longpoll dispatch by the cost of one rpc roundtrip.
source.local.1.longpoll.native.disableVerification=false
### this is the password string that should be sent by the other end when notifiying of a block change.
source.local.1.longpoll.native.passphrase=my-very-obscure-string
### comma delimited string, you may need to include the ipv6 the address as well.
source.local.1.longpoll.native.allowedHosts=127.0.0.1,localhost
#################################
# Local Source Only Config #
#################################
### The following settings are only relevant to local sources:
### allow non getwork requests to be passed through to this source as a proxy.
### If true methods allowed are filtered by source.local.1.allowPassthruMethods
### getblocknumber is always allowed and returns the latest block number from any source
source.local.1.allowJSON-RPCPassthru=false
### comma delimited list of method names that are allowed to pass through.
### default is none. getwork is always allowed.
source.local.1.allowedPassthruMethods=
### defaults to min difficulty: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
### don't know why you'd want different difficulty per source but it's there if you need it.
#source.local.1.rewriteDifficultyTarget=ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
###default true = set to false if you want to PoolServerJ as a proxy for non-pool mining
#source.local.1.rewriteDifficulty=false
##################################################
## Local Source 2 #
##################################################
source.local.2.disabled=true
### This should be unique. If you are not using pushpool compatability mode for logging then this will be added
### to share logs so you can track where the shares are going.
source.local.2.name=bitcoind-local-2
### url including port i.e. http://localhost:8332/
source.local.2.url=http://localhost:8330/
### json-rpc username - for standard bitcoind this is set in bitcoin.conf (rpcuser)
source.local.2.username=smart
### json-rpc password - for standard bitcoind this is set in bitcoin.conf (rpcpassword)
source.local.2.password=smart
### Perhaps the most important setting, weighting determines how many requests will come from each source.
### The approximate percentage of requests serviced but this source is weighting / sum(all weightings) * 100.
### e.g. if you have source.local.1.weighting=25 and source.remote.1.weighting=75, 25% of requests will be serviced
### by source.local.1
source.local.2.weighting=5
### this is per source, so don't go overboard if you've got multiple sources or you might clog up your machine with masses of concurrent threads
### with a local client testing has shown 10 is a good number. More or Less reduced performance. For high latency connection you may want to try higher.
### BUT if the source supports multiget mode you probably don't want this much higher than 3.
source.local.2.maxConcurrentDownloadRequests=20
### no need to go to high since submits are far more rare than requests.
source.local.2.maxConcurrentUpstreamSubmits=3
### in seconds - age is the time between now and when the work was fetched from the source.
source.local.2.maxWorkAgeToFlush=30
### in milliseconds = max 1000
source.local.2.minIntervalBetweenHttpRequests=0
### in milliseconds = max 1000 - alternate value used immediately after a block change
source.local.2.minIntervalBetweenHttpRequestsWhenFrantic=0
### max works to cache. Server will continually poll upstream until the cache has reached this limit.
### as soon as it drops under this number it will start polling again to keep the cache full.
### work can be removed from cache either by delivering to a client or by sitting there for longer than
### maxWorkAgeToFlush
source.local.2.maxCacheSize=100
### maximum time in milliseconds to wait for the cache to return work before giving up and returning an error result.
source.local.2.cacheWaitTimeout=30000
### The following settings are only relevant to local sources:
### allow non getwork requests to be passed through to this source as a proxy.
### If true methods allowed are filtered by source.local.1.allowPassthruMethods
### getblocknumber is always allowed and returns the latest block number from any source
source.local.2.allowJSON-RPCPassthru=false
### comma delimited list of method names that are allowed to pass through.
source.local.2.allowedPassthruMethods=
### defaults to min difficulty: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
### don't know why you'd want different difficulty per source but it's there if you need it.
#source.local.2.rewriteDifficultyTarget=ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
###default true = set to false if you want to PoolServerJ as a proxy for non-pool mining
#source.local.2.rewriteDifficulty=false
