Bitcoin Forum
December 03, 2016, 09:59:07 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
Author Topic: PoolServerJ - Tech Support  (Read 26336 times)
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 10, 2012, 03:21:14 AM
 #101

I already told you what happens

your running your pool on the same box as Ubuntu xwindows

and your actively using xwindows

and browsing the web with firefox and all kinds of other crap

and its slowing the already less then capable machine down and Bitcoin RPC cant keep up with requests from the Pool


I saw all the processes on that machine, you cant expect the pool to operate at full speed when your running it as a workstation computer for web browsing and all kinds of regular use, there are not that many resources available to that machine to begin with - you need them reserved for the pool - running a pool takes a sh1t load of resources dude its not like a regular thing - especially when you are merged mining three different coins

running a pool takes a lot of resources and if the machine its on inst super fast it takes a dedicated one at the very least.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
January 15, 2012, 05:27:51 PM
 #102

Quote
5619 [shared-httpclient-60] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
5623 [shared-httpclient-60] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
5627 [shared-httpclient-61] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[17:41:28.137] [WARN] Bad HTTP response connecting to auxDaemon http://localhost:8335.  Work generated from this AuxInfo will not be valid for chain: namecoin. HTTP response code: 401


Dunno what is wrong. Using 0.3.24.64 and get that. Password AND username are correct.

WorkMaker edition, pushpool compatibility is OFF
Bump. I need to fix this, so please, guys help me. I am on the verge of destroying psj.

Thanks to cablepair this is fixed. However, I encountered another problem. After a while PSJ hangs on windows causing Bitcoin-Qt to crash as well.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 16, 2012, 05:20:18 PM
 #103

ive already addressed this issue
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
January 16, 2012, 08:24:51 PM
 #104

I was browsing on your comments in this thread, and there was nothing about PSJ crashing ?coind. Even namecoind crashed. After trying to restart PSJ via Ctrl+C the threads dont quit so I have to manually kill the java process

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
January 16, 2012, 08:48:06 PM
 #105

I was browsing on your comments in this thread, and there was nothing about PSJ crashing ?coind. Even namecoind crashed. After trying to restart PSJ via Ctrl+C the threads dont quit so I have to manually kill the java process
It crashes my ?coind I have them set to auto restart.
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 17, 2012, 12:21:01 AM
 #106

yeah

the funny thing is the last two times one of my pools crashed bitcoind with poolserverj it was because it solved a block

i wish shads would come back and continue developing this...

btw:

Right now I am merged mining btc/nmc/dvc with poolserverj and attempting to add i0 ad ix later tonight

am i the first person to do this? anyone else attempt more than just nmc with psj?
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
January 17, 2012, 12:31:02 AM
 #107

Do all the standard precompiled clients of all alt-chains support merged mining? I.e do I need to compile them with mm support? Cause bitcoin has the rpc command getmemorypool, but namecoin does not.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 17, 2012, 12:34:17 AM
 #108

not all chains do

btc/nmc/dvc/i0/ix are officially merged compatible right now, but im sure doublec's patch could be applied to any of them.
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
January 17, 2012, 01:18:47 AM
 #109

not all chains do

btc/nmc/dvc/i0/ix are officially merged compatible right now, but im sure doublec's patch could be applied to any of them.
btc is only able to be used as a 'parent' chain. It can't be an auxiliary chain. It requires a block chain fork for a chain to be changed to support use as an auxiliary chain.
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 17, 2012, 01:21:02 AM
 #110

i understand that Smiley

my only concern right now is the way poolserverj uses weighting for merged mining

im having a bit of a difficult time trying to determine what the best weight is for bitcoin as parent and nmc/dvc/i0/ix as aux

cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 17, 2012, 06:33:17 PM
 #111

Well I have bad news - and a very good reason why we need shads (or some other very skilled and brilliant coder) to come work on this awesome project!

After extensive testing on multiple pools and also getting reports from other pool admins

I have come to the conclusion that (although its supposed to) merged mining of more than one aux chain does not work with PSJ at the current time.

You can add multiple merged mining aux chains, and you can have everything running pretty with no errors
but the only blocks that will ever solve are the parent (bitcoin) and which ever aux chain you declare first.

I have tested this on multiple pools with multple aux chains multiple times in multiple different scenarios and I am 100% convinced of this to be true

if anyone can prove me wrong I would love to see it but unfortunately I know I am right.

I assume since at the time he created PSJ / NMC was the only merged mining compatible aux chain he was not able to actually test if this worked or not.

Shads we need you!!

DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
January 17, 2012, 07:02:06 PM
 #112

Well I have bad news - and a very good reason why we need shads (or some other very skilled and brilliant coder) to come work on this awesome project!

After extensive testing on multiple pools and also getting reports from other pool admins

I have come to the conclusion that (although its supposed to) merged mining of more than one aux chain does not work with PSJ at the current time.

You can add multiple merged mining aux chains, and you can have everything running pretty with no errors
but the only blocks that will ever solve are the parent (bitcoin) and which ever aux chain you declare first.

I have tested this on multiple pools with multple aux chains multiple times in multiple different scenarios and I am 100% convinced of this to be true

if anyone can prove me wrong I would love to see it but unfortunately I know I am right.

I assume since at the time he created PSJ / NMC was the only merged mining compatible aux chain he was not able to actually test if this worked or not.

Shads we need you!!



Sorry I did not know you were testing this but Shadders told me it only works for one aux chain.
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 17, 2012, 07:52:11 PM
 #113

Did he say if/when he is going to fix it? This is too good of a project to let die
DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
January 18, 2012, 12:38:40 PM
 #114

Did he say if/when he is going to fix it? This is too good of a project to let die
Last time I talked to him was when he posted and said he would be back during the holidays so I don't know if he is coming back.
MORA
Full Member
***
Offline Offline

Activity: 126



View Profile
January 18, 2012, 05:28:55 PM
 #115

Sorry if this may be horribly obvious.

I got the poolserver working on litecoin, and added a few clients to it, they were hashing away and getting longpool events.

However I dont see shares being logged, neither to DB or file.
As I understand, a share is each time cpuminer prints out a stat line, right ?
In that case it should have logged a few 100shares, but no errors and no data in the shares file.

When starting it, it does say RETRY a few times, but then runs and looks to be working.

Any ideas what could be the reason for no log?

DavinciJ15
Hero Member
*****
Offline Offline

Activity: 750


Bitcoin - helping to end bankster enslavement.


View Profile WWW
January 18, 2012, 05:33:38 PM
 #116

Sorry if this may be horribly obvious.

I got the poolserver working on litecoin, and added a few clients to it, they were hashing away and getting longpool events.

However I dont see shares being logged, neither to DB or file.
As I understand, a share is each time cpuminer prints out a stat line, right ?
In that case it should have logged a few 100shares, but no errors and no data in the shares file.

When starting it, it does say RETRY a few times, but then runs and looks to be working.

Any ideas what could be the reason for no log?
You did not give PSJ permissions  also you need to turn on trace debug in you settings file to see errors on the screen.
MORA
Full Member
***
Offline Offline

Activity: 126



View Profile
January 18, 2012, 07:46:30 PM
 #117

You did not give PSJ permissions  also you need to turn on trace debug in you settings file to see errors on the screen.

Permissions should be ok, in MySQL I granted it all, and I just tested that I can insert to shares table with same login, also it didnt complain about the user logins, that I created in user table (but then again I didnt check with a user that would fail, dont know if it falls back to no check if theres DB problems).

enabling trace=all gives alot of these
[20:39:05.159] TRACE[blockmon_firecheck] Sleeping timed block check cycle for source: litecoin-1.litecoin 0ms
[20:39:05.169] TRACE[blockmon_firecheck] Firing timed block check for source: litecoin-1.litecoin overdue by 10ms

but even with those removed form the log, there does not seem to be any actual errors logged.

cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
January 18, 2012, 08:18:37 PM
 #118

do you import the poolserver.sql tables into your database and make sure the ma mappings are correct in the psj conf?
MORA
Full Member
***
Offline Offline

Activity: 126



View Profile
January 18, 2012, 08:52:53 PM
 #119

do you import the poolserver.sql tables into your database and make sure the ma mappings are correct in the psj conf?
Imported yes.
I didnt change the mappings, but used those in single mine example.
I have checked that the fields exist.

Retard
Prime Minister
VIP
Sr. Member
*
Offline Offline

Activity: 448


View Profile
January 22, 2012, 06:17:19 PM
 #120

how must it look when the deamons are on a different server?

for example

Merge Mining

Bitcoin // Namecoin server #1 192.168.1.0
PoolserverJ #192.168.1.1

Code:
################################################################
#          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-<listen port>.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=<true|false>&source=<source.name>
### 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 <key>=<value> 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=<myparam>
### 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




Any Idea ?
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!