Print Page - [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED

Title: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 05:51:01 AM

I'm pretty excited about this release. It contains some very significant new features and improves overall performance by several 100%. The merged mining branch of poolserverj has been in alpha for some time and with the help and testing from several pool ops we've been able to stabilise it and iron out most of the MM specific glitches.

The WorkMaker feature represents a fundamental shift the way poolserverj operates. The rpc bottleneck is gone forever so your bitcoin daemons can have a little rest.

I'll go through the major features one by one and full changelog is at the end of this post. But first...

Please do this!

The config options have changed significantly. I highly recommend you start fresh with the sample properties file and transfer your settings over. Trying to do it the other way is going to be a very error prone process. I also recommend you take the time to read the comments in properties file in detail. They are the defacto poolserverj documentation.

Please also make sure you read the 'Default Donation' section of this post. This can be disabled but please be aware that it's there by default.

Recommended minor patch

I highly recommend making this very small patch to you daemons. This simply prevents your debug.log being spammed.

In the file rpc.cpp or bitcoinrpc.cpp search for this line (there may be extra strMethod's in there so search for "ThreadRPCServer method="):

Code:

if (strMethod != "getwork")
        printf("ThreadRPCServer method=%s\n", strMethod.c_str());

and change it to:

Code:

if (strMethod != "getwork" && strMethod != "getworkaux" && strMethod != "getauxblock"
               && strMethod != "buildmerkletree" && strMethod != "getblocknumber" && strMethod != "getmemorypool")
       printf("ThreadRPCServer method=%s\n", strMethod.c_str());

Now onto the new features...

Merged Mining Support

Poolserverj now has a complete native merged mining implementation. It handles all the functions of merged-mining-proxy internally and performs all the additional functions that previously required a merged-mining version of bitcoind. This means that requirements for merged minings are much simpler:

   * No merged-mining-proxy required
   * A stock version of bitcoind that includes the getmemorypool patch (bitcoin 0.5.0 includes this)
   * namecoind merged mining version.
   * Optionally if you want to take advantage of coinbasing on the namecoin chain then you can apply the getmemorypool patch to namecoind (which is very simpe to do)

There are a few gotchas with merged mining we've all discovered over the past few weeks which poolserverj handles:

Partial Stales

When a single chain (e.g. namecoin) finds a new block but the other chain doesn't it's possible for a share to be stale for one but not the other. Poolserverj detects this and sets our_result=1 and reason=partial_stale. Optionally you can also configure a BOOLEAN database column for each chain that will be marked with 1,0 so you can calculate share credits on a per chain basis. This is particularly a problem with cgminer clients (fixed in the latest source code though) who do not respect longpoll unless prev_block_hash has changed. This will only change when a bitcoin block is found so cgminer client can get partial-stales for the namecoin chain quite frequently.

Longpoll Passthrough

To address the double longpoll issue. There is a fundamental design clash between longpolling and merged mining. Basically it works like this: When there is a double block change (i.e. btc and nmc solved by one solution) the daemons won't see the new block at exactly the same time. From what I've seen a delay of around a 1-2 seconds is not unusual. What happens then is that one chain advances to the next block. PSJ checks the other chains to see if they've updated, sees they haven't so starts sending out LPs. Before the miner receives the LP and establishes a new LP connection the second chain advances so PSJ starts sending out another batch of LP's. Those miners who haven't got their new LP connection registered before the second LP miss out so continue working on the old block for as long as they would normally (probably about a minute). This patch addresses this by setting a longpoll passthru period. Where two block changes happen within a specified period (10 seconds). After the 2nd block change and until 10 seconds after the 1st block change has passed, any longpolls received will have a short expiry of 1 second after which they'll return new work to the worker. This will give any slow miners a few seconds to get their longpoll in and learn that there's a 2nd new block to work on. The reason for the 1 second delay is to prevent longpoll spam. Most miners will immediately send another LP request as soon as they get a response. With 0 delay this sets up an LP spam loop. They will still spam 1/sec for up to 10 seconds which is why this is called a workaround rather than a fix. There's really no way to fix this issue properly except to ditch either longpolling or merged mining alltogether.

Experimental SCrypt Chain Support

Currently only litecoin is supported but additional chains can be added relatively easily. All that's required to add new chain support is to define the chain in the source and add a few constants. This hasn't been tested in the field yet.

Database Fault Tolerance

PoolServerj is now highly tolerant to database failures. Connections are retried if they fail.

Workers will continue to be served from the cache in this case and given the default cache expiry of 60 minutes (unless you explicitly flush the worker) this means the only worker impact is that changes to the worker from the front end will not be propagated and new workers will not be able to connect until the DB connection is restored.

Shares will be serialized to disk in batches when the DB is not available. When it comes back online any shares on disk will then start being sent to the database. Shares are stored in batches as separate files so it is perfectly feasible to take these files and give them to a different poolserverj server to upload.

The end result is your database can go offline for a significant period and poolserverj should happily carry on working with no data loss. The only impact will be that workers that have not connected for more than 1 hour will not be able to authenticate.

I have tested this by taking mysql down for an hour with a stress test client submitting about 400 shares /sec. When the database was brought back online it took only a couple of minutes to flush all shares to the database.

WorkMaker

Note that all the variations of WorkMaker and Coinbasing have been tested and proven to work on testnet for both bitcoin and namecoin testnet.

My biggest bugbear with merged mining was the additional overhead it put onto the server to keep track of everything. But... what merged mining taketh away WorkMaker giveth back 10 fold :)

WorkMaker is internal work generation. No more getwork rpc calls to bitcoin daemons which means you can use a stock standard version of bitcoind (as long it's a version that supports the getmemorypool rpc call).

Aside from enabling coinbasing functionality (which I'll discuss below) it offers huge performance benefits.

You may ask "aren't you just moving the CPU load from bitcoind to poolserverj?". Partially... There are two major ways this is a win though:

   1. You eliminate RPC/network latency overhead which is significant for what should be a microsecond operation.
   2. The bitcoin implementation uses a very inefficient algorithm for generating work. The majority of the CPU load comes from hashing. The default implementation requires ~ 2 * nTransactions hashes to generate a work. The poolserverj implementation requires log2(nTransactions). For an average block with 50 transactions this means 100 hashes vs 6. For a large block with say 200 transactions this means 400 hashes vs 8.

Performance

Of course I did some benchmarking to prove the point so here's the numbers...

Raw generation tested by altering poolserverj to consume the work internally so that as soon as it's generated it will try to generate another one...

   * 0.3.0 with JK patched bitcoind daemon: ~2000 works/sec
   * WorkMaker: 24000 works/sec

Frontside getwork capacity - using stress test client with 50 concurrent thread continuously issuing getwork requests. This measures the throughput including RPC overhead:

   * 0.3.0 with JK patched bitcoind daemon: ~1000 works/sec
   * WorkMaker: ~4000 works/sec

The highest frontside getwork rate I've seen in a production environment with 0.3.0 was on one of BTC Guild's servers: 4500 works/sec so it's probably reasonable to guess that this server would be capable of ~15000/sec.

This is only the first iteration and there numerous ways this can be further optimised which will happen in the future.

Coinbasing

So aside from performance what else does workmaker do for you? Because it generates the coinbase transaction internally (similar to luke-jr's coinbaser patch) we have a few options to play with.

Firstly you set the payout address in the properties file. This does not have be associated with the bitcoind you are connected to. It could be an offline secure wallet address if you want. Or if you run multiple instances of poolserverj on different servers you can ensure all coinbase rewards go to a single wallet regardless of which server generated them.

Coinbase message string: There is an option to set a short coinbase message string. I have hardcoded this to be limited to 20 bytes as I don't want to encourage spam in the blockchain. You may want to use some sort of pool identifier or even a private UID.

Coinbasing can also work on namecoin or other aux chains but it requires the getmemorypool patch to be applied. This is a very simple patch to apply, even I was able to do it first go and I'm biggest numpty around when it comes to c++.

Coinbase Donations

It is now possible to set an automatic donation to any address in the coinbase transaction. This can be calculated using 4 different methods:

   1. an absolute value in bitcoins (or fractions)
   2. a percentage of total block reward
   3. a percentage of total block reward excluding transaction fees
   4. a percentage of transaction fees only

Note that I said ANY address. If you are donating and you use open source software from other developers in your pool please consider sending them a tip as well. You can set as many donation targets as you like.

Donations will work on aux chains as well if you set the chain to localCoinbasing=true but you MUST have the getmemorypool patch applied to the aux chain daemon.

Why did I put this feature in?

As many of you know I don't run a pool and I don't even own a mining rig. Donations for development work are my sole source of coins. This is good for poolserverj users because I am not distracted by the day to day stuff of running a pool and I can concentrate on developing the software. In full time hours I could probably measure the time I've spent on poolserverj in months. I never really expected donations but when a few started coming in it was rather nice. And I noticed it gave me a lot more motivation to keep improving the code. This is a simple no hassle way you can help keep me and other open source developers interested and motivated.

If you choose not to use this feature I have no problem with that. There's many reasons people may not (0 fee pools for example) and I'm not going to give any preferential support based on whether people do or don't donate, in fact there no real way I can tell where donations are coming from that I can see. I think the record has shown I've always been happy in the past to give support and advice without the expectation of donations.

Default Donation

The sample properties file is setup with a default donation. You can remove this simply by commenting out those lines. I realise this may be controversial, the reason I've chosen to do it this way is simply so that people have to make a conscious choice to NOT donate. This feature obviously interests me more than other people and I'm sure that if it wasn't the default option many people that may have been happy to donate would not simply because it never crosses their mind to look at the feature. This way everyone who uses it has to stop and think about it for a moment.

The first time you start this version of poolserverj you will be prompted with a warning that this default donation exists. If the file 'donation.ack' exists in the tmp directory you will not see the prompt and poolserverj will start normally.

If anyone genuinely feels they missed the message and donated unwittingly contact me with the blocks involved and as long as I can verify the blocks belong to your pool I'll be happy to send the coins back to the same address that the main coinbase reward was paid to.

Future Development

I'll be maintaining the 0.3.x branch for a short time until the 0.4.x branch is considered stable at which time it will be merged.

Non-merged mining is quite possible with 0.4.0 but it hasn't been extensively tested.

A couple of the next major developments I plan to work on include:

   * Enable poolserverj to listen on multiple ports
   * Binary work protocol to replace frontside RPC. This can reduce bandwidth usage by 85% and will remove the need for longpolling and all it's associated problems.

Full Changelog

From 0.3.0.FINAL to now:

[0.4.0rc1 WorkMaker]

Major Features:

Full merged mining support including longpoll for all aux chains.
Support for SCrypt chains (litecoin, tbx, fbx)
WorkMaker internal work generation (more than 10x faster than rpc with JK patched daemons)
Coinbasing to any payout address both for parent chain and aux chains (aux chain daemon must have getmemorypool patch applied to use this feature)
Donations via coinbase transaction. PLEASE READ THE SAMPLE CONFIG AS THERE IS A DEFAULT DONATION WHICH YOU CAN REMOVE.
DB fault tolerance, shares serialized to disk if DB connection is lost and sent to server when connection is reestablished. This means along with Worker caching
you can switch your db off without losing any shares. The only impact will be that new workers will not be able to authenticate and higher than
normal DB load when you switch it back on.

Detailed changes:

- added useragent as an optional column for share logging.
- added support for SCrypt as a proof of work hashing algorithm.
- Update to generate merged mining auxPoW internally. This completely removes the dependency on bitcoind-mm version and allows us to use stock bitcoind which is nifty since it contains getmemorypool and we need that. A point to note: hashes in the 2 merkle branches contained in auxpow are reversed compared to a transaction hash in the main block merkle tree.
- added db.connectionOptions property to allow users to add arbitrary connect paramenters to connection URL.
- Update to share logging to retry failed connections. If the connection is still failed then shares are serialized to disk. The ShareLogger thread periodically checks for shares on the disk and resubmits them to the database. This means shares can survive across a poolserverj restart if the DB is failed for that long. THIS IS AN API BREAKING CHANGE. Any db.engine.shareLogging plugins that inherit from DefaultPreparedStatementSharesDBFlushEngine will need to have their method signatures updated.
- Integrate local block generation for aux chains allowing coinbasing in the aux blocks
- cleaner thread now checks for dead longpoll connections, can only detect connections that have not been silently dropped by the miner.
- added timestamps to logging
- fix: missing block check interval property
- fix: with a single worksource the fetcher was blocking until a new block check was issued and forced all blocks to be marked in sync.
- block checker change sleep() to wait() so if can be woken up with notify
- Refactored all JsonRpc specific code out of WorkSource, ShareSubmitter and BlockChainTracker. bitcoind side of server is now complete abstracted from protocol and transport.
- add case sensitive worker name option (caseSensitiveWorkerNames=false)
- add AnyWorkerFetchEngine that bypasses DB lookup and returns a worker with the requested name. This is for pools that do no have miner accounts and use a payout address as username. Password is set to empty String.
- add blackhole db share flush engine which does nothing. A quick work around for disabling writing shares to db.
- hack to allow properties to return empty String instead of null - use value '~#EMPTY_STRING#~'
- rebuild block tracker to handle multiple chains with different block numbers.
- adjust longpolling to account for additional chains. LP now fires when any chain finds a new block but waits until a getblocknumber has come back from each chain first to try and prevent double LPs. If a daemon is down it will timeout and fire the longpoll anyway after 1 second.
- allow subtractive traceTargets. i.e. 'traceTargets=all,-merged' will show all traceTargets except 'merged'
- fixes for block sync cases where sync tracking loses the plot and never fires block change.
- support for partially stale shares. Where a single chain has advanced to the next block old work may still be valid for the other blocks. This patch checks that the work is valid for at least one block giving three possible outcomes. accepted, accepted partial-stale, stale
- longpoll passthru. To address the double longpoll issue. There is a fundamental design clash between longpolling and merged mining. Basically it works like this: When there is a double block change (i.e. btc and nmc solved by one solution) the daemons won't see the new block at exactly the same time. From what I've seen a delay of around a 1-2 seconds is not unusual. What happens then is that one chain advances to the next block. PSJ checks the other chains to see if they've updated, sees they haven't so starts sending out LPs. Before the miner receives the LP and establishes a new LP connection the second chain advances so PSJ starts sending out another batch of LP's. Those miners who haven't got their new LP connection registered in time miss out so continue working on the old block for as long as they would normally (probably about a minute). This patch addresses this by setting a longpoll passthru period. Where two block changes happen within a specified period (10 seconds). After the 2nd block change and until 10 seconds after the 1st block change has passed, any longpolls received will have a short expiry of 1 second after which they'll return new work to the worker. This will give any slow miners a few seconds to get their longpoll in and learn that there's a 2nd new block to work on. The reason for the 1 second delay is to prevent longpoll spam. Most miners will immediately send another LP request as soon as they get a response. With 0 delay this sets up an LP spam loop. They will still spam 1/sec which is why this is called a workaround rather than a fix. There's realy way to fix this issue except to ditch either longpolling or merged mining alltogether.
- added trace message to indicate longpoll passthru has started/stopped
- add user-agent to request meta-data for future logging to database
- fix for restoreWorkMap. Now that workmaps are not cycled per block the blocknumber is no longer relevent when loading the map from disk. Only work age matters and old works will be cleaned out on the next Cleaner cycle so we simply accept everything from the file into the workmap.
- when retrieving work from cache add validate check to ensure work is not expired and continue polling until one is found that is valid or cache is empty.
- add retry for worker db fetch. If connection fails close and reopen connection then retry query before throwing an exception.
- add litecoin support
- extend fireBlockChange to run in lite mode when block hasn't changed but you want to trigger a cache flush and longpoll (e.g. if a high value transaction come in.)
- rebuild default share logger to use column mappings so all columns can now be optional.
- added components needed to trigger a longpoll when new transaction included in the block increase expected fees by more than a user defined threshold.
- enable workmaker for non-merged mining config
- added forced acknowledgement of default coinbase donations on first startup

[0.3.1]
- security hotfixes for two bugs that allowed duplicate shares to be submitted in specific circumstances.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: makomk on November 08, 2011, 12:06:50 PM

Quote from: shads on November 08, 2011, 05:51:01 AM

When there is a double block change (i.e. btc and nmc solved by one solution) the daemons won't see the new block at exactly the same time. From what I've seen a delay of around a 1-2 seconds is not unusual. What happens then is that one chain advances to the next block. PSJ checks the other chains to see if they've updated, sees they haven't so starts sending out LPs. Before the miner receives the LP and establishes a new LP connection the second chain advances so PSJ starts sending out another batch of LP's. Those miners who haven't got their new LP connection registered before the second LP miss out so continue working on the old block for as long as they would normally (probably about a minute).

The solution I was going to suggest for this was adding an opaque X-Block-ID header to the getwork response that changes every time there's a new block on any of the chains (for example, it could be a counter that increments). Mining software can then be modified to send their own X-Block-ID header in their longpoll requests with the last value they saw, and if it doesn't match what you're expecting then the miner must've missed a block change and the long poll should return immediately.

The nice thing is that this can be combined with your existing workaround; clients that don't send X-Block-ID can get the early longpoll expiry whereas clients that send it don't need to be spammed with extra work.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 12:33:25 PM

I quite like that idea. Poolserverj already maintains an internal 'pseudoblocknumber' which is just the sum of all chain's blocknumbers. This could be used.

Though it would require miner support. And if I'm going to go down the road of cajoling miner devs to support another protocol adjustment I wonder I should just exert the effort getting uptake for a differential binary protocol... I'm going to post a proposed spec for discussion in the next few days. The spec I have in mind would eliminate the need for LP requests altogether.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: makomk on November 08, 2011, 12:54:20 PM

Quote from: shads on November 08, 2011, 12:33:25 PM

Though it would require miner support. And if I'm going to go down the road of cajoling miner devs to support another protocol adjustment I wonder I should just exert the effort getting uptake for a differential binary protocol... I'm going to post a proposed spec for discussion in the next few days. The spec I have in mind would eliminate the need for LP requests altogether.

The reason I'm suggesting this method is because I'm not convinced there's much chance of miner developers implementing an entire new protocol. We already have a binary protocol (https://bitcointalk.org/index.php?topic=3493.0) that should be reasonably easy to implement, but most miners still don't support it. (It's also probably good enough; even without differential updates and with the redundant hash1 and midstate included a getwork response easily fits uncompressed into a single packet.)

Incremental improvements to the existing JSON-RPC way of doing things seem to get a much better reception. No idea why.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 08, 2011, 01:58:52 PM

Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 02:25:32 PM

Quote from: DavinciJ15 on November 08, 2011, 01:58:52 PM

Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?

'coinbasing' or 'coinbaser' as a verb was probably invented by luke-jr. It simply means creating or controlling the coinbase transaction. Every block has 1 or more transactions. Every transaction must reference previous transactions to show where the coins came from (the inputs). The first transaction in the block (the coinbase transaction) has special rules and doesn't need an input. This is where the 50btc reward from finding a block comes from. When you getwork from a bitcoin daemon the coinbase transaction is generated inside the daemon so you can't do anything out of the ordinary with it. It simply pays out 50btc to an address that belongs to the bitcoin wallet that the bitcoin daemon is using. When you generate the coinbase yourself you are replicating what the daemon does but you can do it differently. You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses. As long as you don't break these rules the block is valid and will be accepted by any bitcoin node. In fact you don't even need to submit a winning block to your local bitcoin daemon. You could submit it to any daemon with the getmemorypool patch or you could just broadcast it on the bitcoin p2p network. PSJ actually does this as a backup, it sends getmemorypool then it sends via a p2p connection to the same node using the bitcoin protocol. This is an experimental feature which I've actually seen working a few times, the p2p broadcast was accepted first so the getmemorypool submit was rejected because the block had already been received. This can potentially be extended in future so that PSJ connects to many bitcoin nodes on p2p and broadcasts directly to get the block propagated as quickly as possible and reduce the chance of it conflicting with another block from another miner/pool.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 02:39:36 PM

Quote from: makomk on November 08, 2011, 12:54:20 PM

because it's easier I guess ;)

I don't really go into low level network protocol much these days so I'd be interested to understand the real difference in bandwidth usage between a say a 40 byte message and 200 byte message. I know there are minimum payloads for various protocols but I don't what values for which ones. I know about jgarzik's proposal but to my knowledge there are no implementations so I think refresh of the spec to take current circumstance into account is warranted. I have always argued that everything people complain about with pushpool's design is due to the vastly different state the bitcoin community was in at the time it was design. This protocol was designed at the same time so the same applies.

I agree an RPC extension is more likely to gain quick adoption but if mm has taught me anything it's the power of demand. If demand is satisfied with a quick and dirty approach, i.e. rpc extension, then demand for a better overall solution who's benefits are more strategic will be sucked dry. I wonder if it would be better to just implement a binary protocol with no competing rpc version this creating the choice, implement binary and get benefit or don't... Vs implement binary which is a bit harder and get benefit or implement rpc which is easier and get benefit but get no closer to strategic benefit.

I was intending after discussion of protocol to implement both the PSJ side as well as reference client. This reference client could be easily ported in diablominer. And also farily easily turned into a local proxy that miners could run locally. If at least one client supports it and pools throw their weight behind it (i.e. refuse to add anymore extensions to the rpc protocol) then market forces will push other miner devs to adopt.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 08, 2011, 04:00:58 PM

Quote from: shads on November 08, 2011, 02:25:32 PM

Quote from: DavinciJ15 on November 08, 2011, 01:58:52 PM

Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?

You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses.

A 50btc+ Tx fees do not mature after 120 blocks so how are they paid to an address?

Quote

I highly recommend making this very small patch to you daemons. This simply prevents your debug.log being spammed.

Spammed by who? Users RPC calls made by users via PSJ or directly from exposed bitcoind rpc ports?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 04:14:08 PM

Quote from: DavinciJ15 on November 08, 2011, 04:00:58 PM

Quote from: shads on November 08, 2011, 02:25:32 PM

Quote from: DavinciJ15 on November 08, 2011, 01:58:52 PM

Can you describe what is "Coinbasing" or if you know of a wiki add it to your post?

You can only payout a max of 50btc + transaction fees, but you can pay them out to any address or to any combination of addresses.

A 50btc+ Tx fees do not mature after 120 blocks so how are they paid to an address?

Quote

I highly recommend making this very small patch to you daemons. This simply prevents your debug.log being spammed.

Spammed by who? Users RPC calls made by users via PSJ or directly from exposed bitcoind rpc ports?

spammed by psj making frequent calls to getmemorypool and getblocknumber...

A normal bitcoin block reward is payed out to an address, it just an address the daemon grabs from your wallet that you never see. A coinbased reward is the same except you specify the address from any of your own wallets (or someone else's if you feel so inclined)... It will still show up as a generation transaction and you won't be able to spend it for 120 block like any other generation transaction.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 08, 2011, 04:16:37 PM

Quote

- adjust longpolling to account for additional chains. LP now fires when any chain finds a new block but waits until a getblocknumber has come back from each chain first to try and prevent double LPs. If a daemon is down it will timeout and fire the longpoll anyway after 1 second.

Does this change fix or reduce the number of partial-stales created by cgminer?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 04:27:17 PM

Quote from: DavinciJ15 on November 08, 2011, 04:16:37 PM

Quote

Does this change fix or reduce the number of partial-stales created by cgminer?

No this change was implemented7 before we discovered the cgminer issue. This is the first change to implement longpolling on aux chain blocks being found. Only cgminer can fix the longpoll problems they are having. Its due to cgminer not respecting longpolls properly. A fix has been made by conman in src but I dont think he's made a new release that includes the fix yet

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 08, 2011, 06:32:57 PM

Maybe i did some awesome stupid while trying to start 0.4 but this is what i experienced:

Code:

/poolserverj-0.4.0rc1/bin# java -classpath poolserverj.jar:../lib/*:../lib/lib_non-maven/*:../lib/plugins com.shadworld.poolserver.servicelauncher.PoolServerService start ../conf/local-daemon-mm.properties
Args - [2]: start ../conf/local-daemon-mm.properties
PoolServerJ Service Starting Tue Nov 08 18:30:58 CET 2011
[18:30:58.816] user.dir: /****/poolserverj-0.4.0rc1/bin
[18:30:58.817] Home path set to: /****/poolserverj-0.4.0rc1/bin/poolserverj.jar
[18:30:58.817] Home directory set from jar file location to: /****/poolserverj-0.4.0rc1
#####################################################################
###                PLEASE READ THIS                               ###
###                                                               ###
### PoolServerj contains the capability to send donations via     ###
### the coinbase transaction.  The provided sample properties     ###
### file is configured to send a small donation to the            ###
### poolserverj developer.  You can remove this if you want to.   ###
###                                                               ###
### This warning is intended to ensure you are aware that it      ###
### exists and will not appear again once you acknowlege it.      ###
###                                                               ###
### If you have read this warning and would like to continue      ###
### please indicate that you agree you are aware of the default   ###
### donation by typing 'I agree' at the prompt.                   ###
#####################################################################

Do you agree that you are aware of the default donation? : I agree
[18:31:00.969] Failed to read from console
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:883)
        at com.shadworld.poolserver.conf.Conf.doDonationWarning(Conf.java:298)
        at com.shadworld.poolserver.conf.Conf.update(Conf.java:263)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:189)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:175)
        at com.shadworld.poolserver.PoolServer.<init>(PoolServer.java:113)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:98)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Red Emerald on November 08, 2011, 06:35:05 PM

This looks great. I'm definitely going to play with this over the weekend.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Pontius on November 08, 2011, 08:31:16 PM

@urstroyer: I was too stupid to find the source code for 'com.shadworld.poolserver.conf.Conf.doDonationWarning()' at the bitbucket repo so I don't know what's happening there but good ol' strace -f -e trace=file ... helped.

Do this and psj will start.

Code:

mkdir /****/poolserverj-0.4.0rc1/tmp
touch /****/poolserverj-0.4.0rc1/tmp/donation.ack

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 08, 2011, 09:24:17 PM

Quote from: Pontius on November 08, 2011, 08:31:16 PM

Code:

mkdir /****/poolserverj-0.4.0rc1/tmp
touch /****/poolserverj-0.4.0rc1/tmp/donation.ack

Here we got! That worked, thanks a lot! <3

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 08, 2011, 10:27:44 PM

ahh sorry, forgot to make the parent directory before creating the donation.ack file. Mine already existed so didn't catch this one. Bug fixed and commited to repo.

Pontius' workaround is correct... If the tmp/donation.ack file exists you won't ever see this message again.

rc2 is uploading now. Should be done in about 10 mins. Only difference is the above bug.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 03:36:10 AM

I have a few issues with the below query...

Code:

db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);

1. id = (?) Should it not be id IN (?) if you want to get a list of workers you some how know the id of.
2. What is this for how do you know the ids?
3. All MySQL example statements in the config files do not end with ";" can I assume we don't need it?

Also what is?
source.local.1.p2p.hostport

Is that for example the bitcoin port like 8333 is that the port I use?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 04:02:02 AM

Quote from: DavinciJ15 on November 09, 2011, 03:36:10 AM

I have a few issues with the below query...

Code:

db.stmt.selectWorkerList=SELECT * FROM pool_worker WHERE id = (?);

You have a sharp eye! That's not supposed to be there. It's for a feature I've built but not yet enabled. Worker cache preloading. Basically it just does a bulk load of workers that were in the cache last time the server was shutdown. This is because the worker select process isn't really designed to be done en masse because it hardly ever needs to be but if a busy server is restarted with lots of workers connected it will start with an empty cache then get a flood of auth requests so has to do a whole heap of single selects.

1/ yes it should IN (?)
2/ psj dumps the id's to a file when it shuts down
3/ no they don't need it. The jdbc driver adds a ;

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 04:13:42 AM

What is?
source.local.1.p2p.hostport

Is that for example the bitcoin p2p port people open on the firewall to get more connections like 8333 is that the port I use for that setting?

Also how come there is no setting for the Aux chain should I add one...

source.local.1.merged.namecoin.p2p.hostport

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 09, 2011, 04:33:00 AM

While running psj 0.4 under load i get spammed with those messages:

Code:

43559 [main-con-qtp-103] WARN org.eclipse.jetty.util.log - /
java.lang.NullPointerException
        at com.shadworld.poolserver.WorkProxy.validateWork(WorkProxy.java:278)
        at com.shadworld.poolserver.WorkProxy.handleRequest(WorkProxy.java:431)
        at com.shadworld.poolserver.servlet.PoolServerJServlet.getResponse(PoolServerJServlet.java:26)
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doRequest(AbstractJsonRpcServlet.java:255)
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doPost(AbstractJsonRpcServlet.java:113)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1352)
        at org.eclipse.jetty.servlets.QoSFilter.doFilter(QoSFilter.java:205)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
        at org.eclipse.jetty.server.Server.handle(Server.java:341)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
        at java.lang.Thread.run(Thread.java:662)

Any idea? Or more logfiles needed?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 05:04:55 AM

Quote from: DavinciJ15 on November 09, 2011, 04:13:42 AM

it's the bitcoin protocol port of yr bitcoind. For sending blocks via bitcoin protocol as a backup in case rpc craps itself.

There's no setting for aux chains as I haven't implemented it for them. I'm still thinking about whether this is really useful or not...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 05:37:00 AM

When I connect one single user to it I get this error message...

Code:

java.lang.NullPointerException
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doRequest(AbstractJsonRpcServlet.java:138)
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doPost(AbstractJsonRpcServlet.java:113)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:476)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
        at org.eclipse.jetty.server.Server.handle(Server.java:341)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
        at java.lang.Thread.run(Unknown Source)

I notice this on start up and just so you know I did a cURL and it worked and then I copied and pasted the username password and URL into settings file so I don't look silly once again..

Code:

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY
[05:25:51.760] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.761] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.761] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/
[05:25:51.778] Updating donation target address for chain: namecoin Address: NFja75nNRHZYKtN9YQ6wHPQdmhzBEAmTAt
[05:25:51.787] Updating donation target address for chain: bitcoin Address: 1Lk8f18EyPB3uAJvgTeHgzCVkKY9njQ5bA
752 [main] INFO com.google.bitcoin.core.NetworkConnection - Connected to peer: version=32464, subVer='', services=0x1, time=Wed Nov 09 05:25:51 UTC 2011, blocks=152492
[05:25:51.788] Established outbound p2p connection to ms2.nmcbit.com:8333
[05:25:51.820] RETRY
[05:25:51.824] New Block detected [26967] from source: DaemonSource[cs40].nameco

not sure what I missed.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 05:51:19 AM

yes I'm just working on that issue... was reported elsewhere as well..

Keep the reports coming...

http://poolserverj.org/dist/poolserverj-0.4.0rc3-mini-binary.tar.gz fixes urstroyers issue

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 05:53:16 AM

Quote from: urstroyer on November 09, 2011, 04:33:00 AM

While running psj 0.4 under load i get spammed with those messages:

Code:

43559 [main-con-qtp-103] WARN org.eclipse.jetty.util.log - /
java.lang.NullPointerException
        at com.shadworld.poolserver.WorkProxy.validateWork(WorkProxy.java:278)
        at com.shadworld.poolserver.WorkProxy.handleRequest(WorkProxy.java:431)
        at com.shadworld.poolserver.servlet.PoolServerJServlet.getResponse(PoolServerJServlet.java:26)
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doRequest(AbstractJsonRpcServlet.java:255)
        at com.shadworld.poolserver.servlet.AbstractJsonRpcServlet.doPost(AbstractJsonRpcServlet.java:113)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1352)
        at org.eclipse.jetty.servlets.QoSFilter.doFilter(QoSFilter.java:205)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
        at org.eclipse.jetty.server.Server.handle(Server.java:341)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
        at java.lang.Thread.run(Thread.java:662)

Any idea? Or more logfiles needed?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 05:54:09 AM

see previous post

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 05:59:07 AM

Quote from: shads on November 09, 2011, 05:54:09 AM

see previous post

Thanks I fixed my previous problem it was the database settings.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 06:03:32 AM

Quote

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY

This error is fiddly and will take a couple of hours before I can fix it... As a work around I think it will work ok if you use 127.0.0.1 in the url instead of localhost

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 06:19:35 AM

Quote from: shads on November 09, 2011, 06:03:32 AM

Quote

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY

This error is fiddly and will take a couple of hours before I can fix it... As a work around I think it will work ok if you use 127.0.0.1 in the url instead of localhost

rc3 didn't live very long.

http://poolserverj.org/dist/poolserverj-0.4.0rc4-mini-binary.tar.gz

This should at least ensure the above error doesn't happen if you use IP. I think it will work if you hostname as well but can't be sure until later today when I've got time to test properly

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 06:51:59 AM

Found a POW and it did not send the coins to the address I specified it remains on the namecoin wallet that PSJ0.4 is connected to.

Am I missing something? Is the coins sent after they mature? But you said it should send them on POW.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 07:02:51 AM

Quote from: DavinciJ15 on November 09, 2011, 06:51:59 AM

If you've got: source.local.1.merged.namecoin.localCoinbasing=true

but haven't applied the getmemorypool patch to namecoind it will fall back to non-coinbasing mode automatically.

either it's set to false (or commented out) or no patch.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 07:25:58 AM

BTW something to keep in mind... even though found blocks are submitted by getmemorypool BEFORE they are sent on the bitcoin network. This is asynchronous and occasionally the daemon will see and process the block from bitcoin protocol first. If this happens getmemorypool will return 'false' because it's already seen the block. This means your upstream_result will be false even though it was actually true.

I'm still not sure whether to keep the p2p connection in place. I could move the code to ensure it always happens after the getmemorypool call but that kind of defeats the purpose. If the rpc call get's hung up for a few second only to fail that's precious seconds where you could have sent the block and someone else might beat you to it...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Pontius on November 09, 2011, 08:51:07 AM

shads, as I wrote before I was unable to find the class where the "doDonationWarning()" method comes from.
Maybe I pulled the wrong release from bitbucket, maybe I'm just blind. Can you give me a hint where to look for it?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 08:53:42 AM

It's in the Conf class but you need to switch to the work-maker-prep branch or you won't see it.

The problem in that method has been fixed and committed though. This is the commit: https://bitbucket.org/shadders/bitcoin-poolserverj/changeset/349c9bc35494

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Pontius on November 09, 2011, 08:59:53 AM

Ahhh, it's located in another branch. Ok, that explains. :D
Thanks a lot.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 01:22:50 PM

Quote from: shads on November 09, 2011, 07:02:51 AM

Quote from: DavinciJ15 on November 09, 2011, 06:51:59 AM

I have notices there is no option for parent block chain "localCoinbasing".
is it

source.local.1.localCoinbasing=true

or
source.local.1.localWorkGeneration.localCoinbasing=true

or is the default?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 01:26:16 PM

localWorkGeneration includes coinbasing as part of the process (it has to)... The reason I called aux chains 'coinbasing' is because you don't actually generate work for the aux chains. You just generate the block.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 01:43:51 PM

After updated to the newest update PSJ stopped working I even undid the last change to the settings (localCoinbasing) this is what I get and my miners do not mine anything.

Code:

[13:29:39.117] RETRY
[13:29:39.120] RETRY
[13:29:39.122] Updating donation target address for chain: namecoin Address: NFja75nNRHZYKtN9YQ6wHPQdmhzBEAmTAt
[13:29:39.125] New Block detected [152552] from source: DaemonSource[cs40].bitcoin - 0 lagging sources.
[13:29:39.127] New Block detected [27023] from source: DaemonSource[cs40].namecoin - 0 lagging sources.
[13:29:39.127] Restoring workmap from file: /home/ec2-user/poolserverj-0.4.0rc2/tmp/workmap-8332.bin
[13:29:39.130] Updating donation target address for chain: bitcoin Address: 1Lk8f18EyPB3uAJvgTeHgzCVkKY9njQ5bA
[13:29:39.533] Retrieving worker from database: davincij@gmail.com_dw_1
[13:29:43.878] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:178)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[13:29:48.889] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:178)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[13:29:49.201] 26 shares in 1,320,845,440 seconds. Current hashRate: 0 GH/s
[13:29:49.201] Submit Throttling on: false
[13:29:49.201] Doing database flush for Shares: 26
[13:29:49.257] Flushed 26 shares to DB in 56.0ms (464/sec)
[13:29:53.896] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:178)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)

NOTE:

Soon as I role back to RC3 everything works fine.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 01:49:19 PM

client hasn't been initialised before workmaker tries to use... Does the message stop after a few seconds?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 02:28:47 PM

Quote from: shads on November 09, 2011, 01:49:19 PM

client hasn't been initialised before workmaker tries to use... Does the message stop after a few seconds?

I waited a bit and tried to mine and it would not let me.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 09, 2011, 02:50:51 PM

I thought you couldn't run rc3 because of?

Code:

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY
[05:25:51.760] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 03:13:46 PM

Quote from: shads on November 09, 2011, 02:50:51 PM

I thought you couldn't run rc3 because of?

Code:

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY
[05:25:51.760] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/

No, 3 worked fine I was just pointing the above out, I had problems at first but I mentioned I fixed them in another post.

However after rolling back to 3 it worked for a while and now stopped working for some reason not sure why when It was working all night long.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 09, 2011, 06:24:55 PM

Hi

I am also upgrading to 0.40rc1 can someone explain : source.local.1.p2p.hostport=localhost:8373
and what this does?

thanks

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 09, 2011, 06:52:39 PM

Quote from: cablepair on November 09, 2011, 06:24:55 PM

Hi

I am also upgrading to 0.40rc1 can someone explain : source.local.1.p2p.hostport=localhost:8373
and what this does?

thanks

Yep: thats the port where bitcoind connects to the network (default: 8333, if you doesn't change the port in your Bitcoin.conf).

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 09, 2011, 07:15:08 PM

thanks for the response. Do I need bitcoind 0.50 for this to work properly?

I have setup pushpool successfully quite a few times, this is my first attempt with poolserverj and I got it running but am having a hard time

[11:17:53.891] Realm resolved null for key: localhost:8331/ Realm: jsonrpc
177913 [shared-httpclient-88] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[11:17:53.891] RETRY
[11:17:53.892] Realm resolved null for key: localhost:8331/ Realm: jsonrpc
177914 [shared-httpclient-63] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[11:17:53.892] RETRY
[11:17:53.893] Realm resolved null for key: localhost:8331/ Realm: jsonrpc
177915 [shared-httpclient-69] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[11:17:53.893] RETRY
[11:17:53.903] getblocknumber response status: 401 for url: http://localhost:8330/
[11:17:53.903] getblocknumber response status: 401 for url: http://localhost:8330/
[11:17:53.904] getblocknumber response status: 401 for url: http://localhost:8330/
[11:17:53.904] getblocknumber response status: 401 for url: http://localhost:8330/
[11:17:53.904] getblocknumber response status: 401 for url: http://localhost:8330/
[11:17:53.904] Realm resolved null for key: localhost:8331/ Realm: jsonrpc
177927 [shared-httpclient-105] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc

anyone got any ideas for me? thanks!!!

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 09, 2011, 07:26:07 PM

Quote from: cablepair on November 09, 2011, 07:15:08 PM

You need a bitcoind with getmemorypool rpc call. Grab version 0.5 here https://github.com/bitcoin/bitcoin or apply an existing getmemorypool patch to a previous version.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 09, 2011, 08:13:31 PM

RC3 works fine now. After rolling back to an older settings file I will do more testing.

On a side note I would like to add a feature request... Where do I add those again?

Anyhow my request is to accept Tx that should have a fee because of the size but do not because the user recoded bitcoin or namecoin to send out a Tx without a fee. I want to create a zero fee node. Also a there should be a max number of illegal zero fee tx that it will include into the next block if possible.

This feature request can be done at your leisure. If you (shadders) are wondering why I would want this msg me on the IRC and I will tell you.

Cheers

Davinci

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 09, 2011, 09:23:31 PM

yeah I think I fixed all my problems simply by compiling a new namecoind and bitcoind 0.5

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: ThiagoCMC on November 10, 2011, 09:17:03 AM

Guys,

Just a newbie question:

Is it possible to create a pool with merged-mining enabled for: Bitcoin, Namecoin and Litecoin?

As a miner, do I still need CGMiner, for Bitcoin/Namecoin and Minerd for Litecoin?!

Also, I would like to first, start just a Litecoin pool, with merged-mining disabled... So, can you guys provide at the final poolserverj-0.4.0.tar.gz a conf-example for each chain isolated and, a conf-example for merged-mining enabled for the 3 chains (BTC/NMC/LTC)?

For the web interface, is there only Simplecoin and Coinmines with PSJ support out there?! I like mmcFE very much... :)

Best!
Thiago

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: eleuthria on November 10, 2011, 11:11:01 AM

Testing of the new build is going great for BTC Guild. Took a bit of tinkering after you first launched, but the bug fixes we found definitely seem to be going smooth. Looking hopeful for full deployment at BTC Guild this weekend! Just waiting on a valid namecoin block to be generated before I attempt a push to live.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 10, 2011, 11:26:13 AM

Quote from: ThiagoCMC on November 10, 2011, 09:17:03 AM

Litecoin is not merged mining capable as far as I know. And even if it was you wouldn't be able share hashes as it uses SCrypt proof work instead double sha256. You'd be able to run a scrypt chain merged mining group and sha merged mining group in separate poolerverj instances but not combined into one.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 10, 2011, 01:19:58 PM

Quote from: DavinciJ15 on November 09, 2011, 03:13:46 PM

Quote from: shads on November 09, 2011, 02:50:51 PM

I thought you couldn't run rc3 because of?

Code:

[05:25:51.758] Realm resolved null for key: ms2.nmcbit.com:9098/ Realm: jsonrpc
722 [shared-httpclient-38] WARN org.eclipse.jetty.util.log - Unknown Security Realm: jsonrpc
[05:25:51.758] RETRY
[05:25:51.760] getblocknumber response status: 401 for url: http://ms2.nmcbit.com:8337/

I am having this exact same error, anyone know the fix for it?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 10, 2011, 02:17:43 PM

which RC are you using?

Depending on which you can try putting in the ip address instead of hostname

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 10, 2011, 02:33:37 PM

just posted rc5 mini binary.

It should fix this issue:

Code:

[06:07:45.255] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:178)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)

There is a problem currently with namecoin blocks being rejected by the namecoind. I won't be able to follow this up in detail until tomorrow. Of course it worked perfectly in test environment but things are different out in the wild I guess...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 10, 2011, 03:29:26 PM

thanks so much for all your support shads, I will be sure to send a donation once I get this working

It looks a lot better now but I still can't connect miners

Quote

PoolServerJ Service Finished Thu Nov 10 07:23:51 PST 2011
[07:23:51.700] RETRY
[07:23:51.703] RETRY
[07:23:51.719] New Block detected [152716] from source: DaemonSource[bitcoind-mm].bitcoin - 0 lagging sources.
[07:23:51.735] New Block detected [27224] from source: DaemonSource[bitcoind-mm].namecoin - 0 lagging sources.
[07:23:51.736] Restoring workmap from file: /home/smart/Downloads/poolserverj-0.4.0rc2/tmp/workmap-8332.bin
[07:23:55.682] Exception in Cleaner Thread
java.lang.NullPointerException
at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:180)
at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[07:24:08.689] Checking for previously failed share commits.
[07:24:10.738] Exception in Cleaner Thread
java.lang.NullPointerException
at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:180)
at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[07:24:18.704] Checking for previously failed share commits.
only [07:24:28.720] Checking for previously failed share commits.
[07:24:38.735] Checking for previously failed share commits.
[07:24:43.936] Retrieving worker from database: test1
[07:24:48.753] Checking for previously failed share commits.
[07:24:58.768] Checking for previously failed share commits.
[07:25:08.784] Checking for previously failed share commits.

What is this Exception in Cleaner Thread and is it what is preventing mining from connecting?
looks like its connecting to rpcs

Quote

[07:23:51.719] New Block detected [152716] from source: DaemonSource[bitcoind-mm].bitcoin - 0 lagging sources.
[07:23:51.735] New Block detected [27224] from source: DaemonSource[bitcoind-mm].namecoin - 0 lagging sources.

it tries to retrieve worker from database...

Quote

[07:24:43.936] Retrieving worker from database: test1

but cgminer does not connect ;/

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 10, 2011, 03:40:31 PM

yes the problem is that the jsonrpc client is null... something must be going wrong when it's initialised. Is that with rc5? If so can you send me yr psj properties file. Just paste it into a PM but don't forget to blank your passwords.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 10, 2011, 06:21:55 PM

ok I have narrowed this down a bit

I have poolserverj Up and running

I can connect to the rpc via firefox with a user/pass from the database

but its not giving work

check this out

Quote

{
"error": {
"code": -31001,
"message": "No work available"
},
"id": 1,
"result": null
}

any help would be amazingly appreciated!

Title: CONFIRMATION ON PRODUCTION NETWORK
Post by: shads on November 10, 2011, 10:58:15 PM

Well I know there's still some glitches being ironed out but we at least have confirmation of real blocks now, both for bitcoin and namecoin

Code:

$cd ~
$tail -c 100000000 ../.bitcoin/blk0001.dat | strings -n 3 | grep BTC
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
$tail -c 100000000 ../.namecoin/blk0001.dat | strings -n 3 | grep BTC
BTC
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
Mined by BTC Guild 
BTC Guild

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 11, 2011, 12:36:17 AM

ok know all running :D

but i dont understand whos testnet works ... surfe name coin and bitcoin testnet=1

and poolserverj config testnet =true

but poolserverj after them didnt started .... any idea whats wrong ?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 12:49:12 AM

Quote from: smart1985 on November 11, 2011, 12:36:17 AM

If you want help you need to give me more useful information than 'didnt start'.

What was the error message?

In this case I can probably guess, you've got production net payout addresses so it's failing address validation.

If you're using the latest rc5 I've added a feature to make switching between testnet/mainnet easier.

All the places where you set a payout address you can add a second entry with '.testnet' appended to the property name. e.g.

Code:

source.local.1.localWorkGeneration.payoutAddress=1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
### this allows you define a testnet address so you don't have to keep
### changing it when you switch to testnet
source.local.1.localWorkGeneration.payoutAddress.testnet=mnn7vBgZgbCXMDts7zFf4xqEpiBWfMEQmQ

psj will pick the appropriate one depending on whether you're on testnet or not

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 12:53:19 AM

If anyone is getting rejected NMC blocks it's proven to work on production network without namecoin coinbasing. e.g. comment out this line:

Code:

#source.local.1.merged.namecoin.localCoinbasing=true

I will figure out what the problem is this weekend but that should get you going in the meantime..

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 11, 2011, 01:07:34 AM

Yes im using the latest Version .

I will try to use poolserverj with merge mining BTC / NMC on a Ubuntu 64 bit maschine.

ok i Added your second Code with .testnet and testnet address .

But after i get this too .

Quote

root@ubuntu:/home/smart/daemons# java -classpath poolserverj.jar:../lib/*:../lib/lib_non-maven/*:../lib/plugins com.shadworld.poolserver.servicelauncher.PoolServerService start ../conf/poolserverj.conf
Exception in thread "main" java.lang.NoClassDefFoundError: com/shadworld/poolserver/servicelauncher/PoolServerService
Caused by: java.lang.ClassNotFoundException: com.shadworld.poolserver.servicelauncher.PoolServerService
   at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: com.shadworld.poolserver.servicelauncher.PoolServerService. Program will exit.

If i want to mine normaly without any testnet config all works.

pool serverJ config

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://127.0.0.1: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=false
### 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 127.0.0.1 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,67.241.55.238,67.249.146.78

################################
# 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=127.0.0.1

db.schema=test
db.port=3306
db.user=smart
db.password=****
### 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.
###

### 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) 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

### 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=false
### 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!
### changing it when you switch to testnet
source.local.1.localWorkGeneration.payoutAddress.testnet=mhYec45ZsjvpRu2G5N8W2RFMWsuBHGCBVY
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://127.0.0.1:8330/
source.local.1.p2p.hostport=127.0.0.1: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=****

#######################
# 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=false
source.local.1.merged.namecoin.payoutAddress=Mz3Qs4eDoE7USV8sjnCf8aATeHCJAtM5Zp
source.local.1.localWorkGeneration.payoutAddress.testnet=mhYec45ZsjvpRu2G5N8W2RFMWsuBHGCBVY
source.local.1.merged.namecoin.url=http://127.0.0.1:8331/
source.local.1.merged.namecoin.username=smart
source.local.1.merged.namecoin.password=****
### @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=****

### 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:

### 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

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 02:54:37 AM

Quote from: smart1985 on November 11, 2011, 01:07:34 AM

But after i get this too .

Quote

This sort of error usually means you've got the wrong jar files in the wrong place. With the mini-binaries you need to find where each of those files is in the main distribution and copy over them.

poolserverj.jar should go into bin directory. The other two should go into lib/lib_non-maven directory.

Also you need to start poolserverj from the bin directory. I just noticed you're in the 'daemons' directory so java can't find poolserverj.jar

I also noticed you've got localWorkGeneration set to false. If you want any of the coinbasing or workmaker benefits you should set it to 'true'.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 11, 2011, 06:48:29 AM

I'am really interested in which daemons are currently recommended for 0.4 release of psj.

As far as i understood:
bitcoind 0.5 (https://github.com/bitcoin/bitcoin)

Anyone got experience in adding the 4diff patch to this release? (https://bitcointalk.org/index.php?topic=22585.msg596872#msg596872)
Does this patch even have any benefits since getwork rpc command is obsolete for current psj release?

namecoind

Which version is the way to go?

https://github.com/vinced/namecoin
or this one here?
https://github.com/namecoin/namecoin

Any patches that have to be applied?

Thanks in advance!

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: eleuthria on November 11, 2011, 07:14:14 AM

Bitcoin 0.5 is the one BTC Guild is using. 4diff is completely pointless with the new PSJ (4diff was almost entirely used for massive getwork optimization, which PSJ doesn't even use anymore).

For namecoind, we used ArtForz's branch: https://github.com/ArtForz/namecoin

The only patches applied were the changes to the debug.log logging on rpc.cpp / bitcoinrpc.cpp to stop it from being too spammy.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 11, 2011, 07:33:32 AM

Quote from: eleuthria on November 11, 2011, 07:14:14 AM

Thanks a lot! Is ArtForz's fork of namecoind confirmed to solve nmc blocks?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 07:43:38 AM

artforz's fork is the one I used for testing. Yes it was confirmed to make coinbased nmc blocks with getmemorypool patch applie but there seems to be a glitch in the release version or some config combinations I didn't account for.

If you don't use coinbasing on the namecoin chain then yes it's confirmed to work.

FYI so far confirmed blocks on mainnet:

8 BTC, 49 NMC

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 11, 2011, 09:02:48 AM

Code:

Oh Yes ... Sorry Shads ,

poolserverj didnt starting with Testnet again. 
If i work without testnet there are all without error`s ... 

[code][24:51:47.071] user.dir: /home/smart/Downloads/poolserverj-0.4.0rc2/bin
[24:51:47.076] Home path set to: /home/smart/Downloads/poolserverj-0.4.0rc2/bin/poolserverj.jar
[24:51:47.076] Home directory set from jar file location to: /home/smart/Downloads/poolserverj-0.4.0rc2
[24:51:47.165] Wrote PID: 11280 to pidFile: /home/smart/Downloads/poolserverj-0.4.0rc2/tmp/poolserverj.pid
[24:51:47.351] Connecting to DB URL: jdbc:mysql://127.0.0.1:3306/test?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[24:51:48.518] Mapped parameter 1 to field 1 (remote_host)
[24:51:48.519] Mapped parameter 2 to field 2 (username)
[24:51:48.519] Mapped parameter 3 to field 3 (our_result)
[24:51:48.519] Mapped parameter 4 to field 4 (upstream_result)
[24:51:48.519] Mapped parameter 5 to field 5 (reason)
[24:51:48.519] Mapped parameter 6 to field 6 (solution)
[24:51:48.519] Mapped parameter 7 to field 7 (time)
[24:51:48.519] Mapped parameter 8 to field 8 (source)
[24:51:48.520] Mapped parameter 9 to field 9 (block_num)
[24:51:48.520] Mapped parameter 10 to field 51 (our_result_bitcoin)
[24:51:48.520] Mapped parameter 11 to field 52 (our_result_namecoin)
[24:51:48.528] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[24:51:48.529] Building Worker-authentication-engine: WorkerAuthenticator.class with extraParams: null
Failed to start
java.lang.NullPointerException
        at com.google.bitcoin.core.Base58.decodeToBigInteger(Base58.java:81)
        at com.google.bitcoin.core.Base58.decode(Base58.java:61)
        at com.google.bitcoin.core.Base58.decodeChecked(Base58.java:98)
        at com.google.bitcoin.core.VersionedChecksummedBytes.<init>(VersionedChecksummedBytes.java:34)
        at com.google.bitcoin.core.Address.<init>(Address.java:55)
        at com.shadworld.poolserver.conf.Conf.configureSources(Conf.java:598)
        at com.shadworld.poolserver.conf.Conf.update(Conf.java:279)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:189)
        at com.shadworld.poolserver.conf.Conf.init(Conf.java:175)
        at com.shadworld.poolserver.PoolServer.<init>(PoolServer.java:114)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:98)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
        at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
PoolServerJ Service Finished Fri Nov 11 00:51:48 PST 2011

-- Datenbank: `test`

CREATE TABLE IF NOT EXISTS `shares` (
  `id` bigint(30) NOT NULL AUTO_INCREMENT,
  `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `rem_host` varchar(255) NOT NULL,
  `username` varchar(120) NOT NULL,
  `our_result` int(1) NOT NULL,
  `our_result_bitcoin` int(1) DEFAULT NULL,
  `our_result_namecoin` int(1) DEFAULT NULL,
  `upstream_result` int(1) DEFAULT NULL,
  `reason` varchar(50) DEFAULT NULL,
  `source` varchar(255) DEFAULT NULL,
  `solution` varchar(257) DEFAULT NULL,
  `block_num` varchar(45) DEFAULT NULL,
  `prev_block_hash` varchar(65) DEFAULT NULL,
  `useragent` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=15 ;

[/code]

Edit :

Yes i do it

### as of v0.5
source.local.1.localWorkGeneration=true
### a valid bitcoin address to receive the payout from the coinbase transaction.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 09:06:44 AM

Quote from: smart1985 on November 11, 2011, 09:02:48 AM

No it works with the correct folder :) but my miner says : No work available
Which setting can i switch now ?

try source.local.1.localWorkGeneration=true

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 09:51:28 AM

it's a bug. If payoutAddress is not set for namecoin. Even if localCoinbasing is false.

As a workaround ensure there's a valid namecoin address even if you aren't using aux chain coinbasing

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 11, 2011, 10:22:47 AM

Quote from: shads on November 11, 2011, 09:51:28 AM

it's a bug. If payoutAddress is not set for namecoin. Even if localCoinbasing is false.

As a workaround ensure there's a valid namecoin address even if you aren't using aux chain coinbasing

Thanks but didnt work.

Im Sure that all Testnet adresses correct.
LocalCoinbasing now on true ... no chance ..

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://127.0.0.1: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=false
### 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 127.0.0.1 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,67.241.55.238,67.249.146.78

################################
#       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=127.0.0.1

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.
###

### 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) 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

### 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!
### changing it when you switch to testnet
source.local.1.localWorkGeneration.payoutAddress.testnet=mhd2AMmpSq1nunVybK3p3ayarLrhqW7aLh
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://127.0.0.1:8330/
source.local.1.p2p.hostport=127.0.0.1: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=smart

#######################
#    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.localWorkGeneration.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY
source.local.1.merged.namecoin.url=http://127.0.0.1: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

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 11:01:17 AM

Quote from: smart1985 on November 11, 2011, 10:22:47 AM

Thanks but didnt work.

Im Sure that all Testnet adresses correct.
LocalCoinbasing now on true ... no chance ..

What's wrong with this picture? :

Code:

source.local.1.merged.namecoin.payoutAddress=Mz3Qs4eDoE7USV8sjnCf8aATeHCJAtM5Zp
source.local.1.localWorkGeneration.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY

try

Code:

source.local.1.merged.namecoin.payoutAddress.testnet=mzCN9ygQm6pf25megFeJqXh6junWbN7JXY

also set localCoinbasing=false

After I've fixed the bug you can set it back to 'true'

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 11, 2011, 11:44:13 AM

lol im so stupid -.- ok ... poolserverj running forward next step stop here

Code:

[03:37:30.826] Exception in Cleaner Thread
java.lang.NullPointerException
        at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:180)
        at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
        at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)
[03:37:43.818] Checking for previously failed share commits.
[03:37:49.308] Retrieving worker from database: test
[03:37:53.856] Checking for previously failed share commits.
[03:38:03.875] Checking for previously failed share commits.
[03:38:13.890] Checking for previously failed share commits.

They say no work available ...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 11, 2011, 12:04:54 PM

Quote from: shads on November 11, 2011, 09:06:44 AM

Quote from: smart1985 on November 11, 2011, 09:02:48 AM

No it works with the correct folder :) but my miner says : No work available
Which setting can i switch now ?

try source.local.1.localWorkGeneration=true

Hey Shads,

I am using the rc5 binary
but I cannot set

Quote

try source.local.1.localWorkGeneration=true

the pool will net accept work with this on

is there a fix for this?

thanks

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 12:22:29 PM

will be going through all the bug reports in detail tomorrow and hopefully sorting them all out...

Quote

but I cannot set
try source.local.1.localWorkGeneration=true

what does this mean? Does something bad happen if you set it? Is you keyboard broken so you can't type the letters? I need detail if you want me to help.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 11, 2011, 12:42:32 PM

sorry shads I just woke up :P

let me give you some detail...

so I kill poolserverj, change in config source.local.1.localWorkGeneration=true

then restart

i get this on console

Quote

Failed to start
java.lang.NullPointerException
   at com.shadworld.bitcoin.p2p.BitcoinDualConnection.shutdown(BitcoinDualConnection.java:133)
   at com.shadworld.bitcoin.p2p.BitcoinDualConnection.startListener(BitcoinDualConnection.java:98)
   at com.shadworld.bitcoin.p2p.BitcoinDualConnection.start(BitcoinDualConnection.java:47)
   at com.shadworld.poolserver.source.merged.JsonRpcMergeMiningLocalWorkMakerDaemonHa ndler.start(JsonRpcMergeMiningLocalWorkMakerDaemonHandler.java:159)
   at com.shadworld.poolserver.source.WorkSource.start(WorkSource.java:154)
   at com.shadworld.poolserver.WorkProxy.start(WorkProxy.java:914)
   at com.shadworld.poolserver.PoolServer.start(PoolServer.java:262)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:99)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
PoolServerJ Service Finished Fri Nov 11 15:35:11 MSK 2011
[15:35:12.117] Retrieving worker from database: tom
[15:35:17.255] RETRY
[15:35:17.257] RETRY
[15:35:17.258] RETRY
[15:35:17.279] New Block detected [27455] from source: DaemonSource[bitcoind-mm].namecoin - 0 lagging sources.
[15:35:17.296] Exception in Cleaner Thread
java.lang.NullPointerException
   at com.shadworld.poolserver.workmaker.WorkMaker.update(WorkMaker.java:180)
   at com.shadworld.poolserver.source.merged.MergedMiningGroup.updateAuxes(MergedMiningGroup.java:249)
   at com.shadworld.poolserver.Cleaner.run(Cleaner.java:54)

and it will not give any work to miners

so I go back to to the config set
source.local.1.localWorkGeneration=false

and restart the server
it will give work to miners but it looks like it is only working on bitcoin network
I could be wrong here but when I run pool serverj with = true
I See New Block Detected both .bitcoin and .namecoin
but if I set = false
i see New Block Detected .bitcoin only

also if I set coinbasing = true for namecoin
I get errors on console
[WARN] cant build aux block chain for name coin reverting to rpc
something to that effect...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 11, 2011, 10:59:31 PM

Quote from: cablepair on November 11, 2011, 12:42:32 PM

sorry shads I just woke up :P

let me give you some detail...

much better :) This info pinpoints several issues for me. I'm having a bugfix marathon today starting as soon as I wake up properly... so hopefully whatever release we have at the end of the today will deal with most of these problems.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 11, 2011, 11:41:52 PM

awesome man, looking forward to it! :) if you wanna see my little personal pool I am testing right now running poolserverj 0.4 w/rc5 binary its at
www.bitminersunion.org

hopefully despite the problems - it is effectively mining for bitcoins at least so I am not wasting my hashes :P

thanks again shads! when I get this all working you can expect a direct donation from me!!! :)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 12, 2011, 08:55:11 PM

any word on the bug fixes?

edit: FYI I just solved my first bitcoin block with 0.40 rc5
http://blockexplorer.com/tx/407bc080c049078cce0f43c08093bae7043bfcaaa219ba2afee5d621f15518e3

very cool :)
dont think merged mining is working though...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 13, 2011, 12:52:51 AM

Quote from: eleuthria on November 11, 2011, 07:14:14 AM

BTW ArtForz has now pulled the getmemorypool into his namecoin fork so you can use it without any modification. Thanks AF :)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 13, 2011, 08:00:09 AM

Quote from: cablepair on November 12, 2011, 08:55:11 PM

edit: make that rc7 not rc6 - found a small glitch in mgmt interface

I've just posted rc7 on the website. I haven't been able to reproduce the bug where coinbasing on namecoin creates invalid blocks. The workaround for this remains the same as above (disable coinbasing) until I can track it.

All the above reported bugs should be either fixed or if not should be giving more debug information which will help to track the source of the problem.

I've also given the management interface a bit of a brush up. It's still quite ugly to look at but the pages now have links to all the simple functions and a help screen to explain the others.

The one I hope you'll take a took at though is the trace function. You can now turn different trace targets on and off without having to restart the server. It will begin with whatever you have set in the properties file. But you can change them as much as you like once the server is started.

Some targets produce a flood of log spam and some only log of certain events so have a play with different ones and please for next couple of weeks at least, turn on as many targets as you can stand so if there's further bugs to sort out we've got as much info as possible to track it down.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 13, 2011, 12:01:15 PM

Im testing ,

looks good at time.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 13, 2011, 12:22:37 PM

Davinci,

I've been running the current version with the properties file you sent me (just changed hostnames and db fields so it would work in my environment). So far found about 10 btc blocks and 1 nmc on testnet. That would suggest the problem is either fixed in the current version, although I didn't change anything I could specifically pinpoint that would have affect this issue, or that the problem is something to do with your daemons. I couldn't see anything wrong with the namecoind source you sent me though.

You might want to try pulling ArtForz latest source, he's pulled the getmemorypool patch and I've confirm that's working as well.

It's a bit odd to be honest. Your log files indicated that the solved block you were sending to namecoind didn't contain the auxpow part. i.e. it was a plain old non-mm namecoin block. The reason that's odd is because the only way it could have gotten one if it was built internally by PSJ. If you set trace=true and traceTargets: work_maker,merged,blockmon then if it happens again it should give the me details I need to track it properly.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 13, 2011, 01:31:57 PM

Shads
rc7 is very good, just like you said fixes all my problems except namecoin coinbasing...

I will send donation now, very good work :)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 13, 2011, 02:32:54 PM

you can only have one parent chain... In theory if you wanted to add a second aux chain you would have to declare it like this:

source.local.1.merged.chains=namecoin,otherchain

Then add all the usual auxchain properties e.g.:

source.local.1.merged.othercoin.chainid=2
etc...

However, The bad news is you can't add litecoin for two reasons:
1/ litecoin is not merged mining enabled
2/ it used the SCrypt algorithm for proof of work (PoW). And the bitcoin/namecoin use double sha256.

If litecoin was merged mining enabled you would have to run a separate instance of PSJ for all the sha256 chains and another for all the SCrypt chains. Combining them is impossible.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Retard on November 14, 2011, 12:00:12 AM

Shads i have a Question :



id = 15
time    2011-11-13 03:30:59
rem_host    xx.131.18.xxx
username    test3
our_result    1
our_result_bitcoin    1
our_result_namecoin    1
upstream_result    0
reason    NULL
reason    bitcoind-mm
source    0000000108cbf7ebc47d556fce8a125ea42ffd6011a8fa24ce...
block_num    64775
prev_block_hash NULL
useragent NULL

Block number and Useragent will fill in without Testnet :D

were can i see which one is a BTC block and which is a NMC block ? There are the DB Query from Testnet ...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 14, 2011, 12:02:58 AM

hey shads

I *think* I have a successfull working BTC/NMC/GeistGeld merged pool,

at least they are all connected

so far I have only mined a bitcoin block successfully and that was before I connected NMC/GG properly

Weird thing is with GG connected it shows Block Hash spam in the poolserverj console window

any ideas?

thanks again bud for all you do!

Quote

0bb2a6fffffffff02700c6a00000000001976a914eea082c5ab901deace80920aa622272a3b7f3c 4588ac40118b05000000001976a914dd2289adb01218e273ebc85f42abf845e464f41988ac00000 00001000000018d51b594ab90cd99771fe9ff2026f504cddaabe123e4fa77ee70a3b62623c04d01 0000008a47304402207ef69e91d004697f40356745e7731d8d35107466e014cc659135b39a18bef f2f0220192ad0ab7ebcee9e1a28d740a1eb9c7d12b3fa39ff9e45915739755286ef934901410486 abcce0c0f7752b864afa47c43ce159f0ec0248ad1e3422f5ff34b3c7cf731248b31560ac04a4724 fde6e2b64312f0074d5436c2ba4ce389b7b5a83cd748d6dffffffff02b02b1c0d000000001976a9 144c88ed63856f22b5eb512e505a1dc5a6ed6b51d888ac00ec6021000000001976a9146efe3215e 6c040a195b409218abd72096862b7c988ac0000000001000000016747140aee53a2d869d5f1a327 997b5d95ba4f999002bac3635e239fd8e1906f000000008b483045022045e2db42501d22ca99781 78b307a3163c72f714927917894a1c11ab198fd64080221008ab5badb0f5a8c99d4c789e2432a63 07062feee4e7d2a3758f25b7f597e838e901410443681e0c8f25f71e093f3b46a75c91315651e00 4ed66781ed5dfa4e639d53096cb95ba93b654080bd5faedd1656d55d107174c6793cd5121b1cc09 8bdbea9190ffffffff024616d516000000001976a9142a68ed6e4b834612ef4322047691914f82f 44ed188acb6833200000000001976a914e9b13b5946bf127f7a6c739478e299996eb75d2588ac00 0000000100000001aa6aff901ee9a2af6586667a2b33396f5b2788ff1eb754f15d4ed38c1598715 3000000008a4730440220410baa533880f87e393934c711250ac385627c8daacc71c967ea60b482 54564d022002b669ea9c294b15507e8a31f67106e815ed1dbf5ad374e555e95a06766e59c901410 4e1f553e0243f93c006d621e35f80ac901440532191545782559e36e81b1a970d13cbca6800ef52 27b12d653218df7904a4e0dad15fc54a812426670a8ffc5461ffffffff02f23b722900000000197 6a91418e96a358ca66c0750ec63906908f0ea6a82400388acb0271403000000001976a9144751d7 19412c156bd7f86194e60c8655311d65ce88ac000000000100000002c3684508c74c5dc524f8da3 780c48aea698a6c7d1c1f6d308b17d3ee5cdb16f5000000008b4830450221009b96ab86406598cc fc6de107d53b68bd513704bde76ffec303b527dac852b12c02202770e53eec82b2f972e860b24b6 8dc0aaf3b53b5ed459d410d791c9fe3a76ac5014104744a3c72d6ef3a205ea2340586d57a7f1590 b603cee87c962e2142c95737731dc8e7a0eb6419de0a0869b02ebde84f46570919fb3d8a7de8103 b79478e4f07deffffffff9892ced678323637ac50eb2a7be7512b2be062041d1649cb7b90d6ce5f bdc6f10a0000008b48304502210099cb8ccbd9ddff55f40463744399881e55cc37f7b9630b2b588 42cf63b7770fa02203e043b1b664c1d622e968532ce5ad81878ccf2cfcbe7c1ac13a97d01ba14d4 da014104f9d20de055659d4dc171878263678ae6d5a6df725a51300f3f8e2c081500dd6c89a0efa 8da39805497651092d60a6aa180517c502606cebe50aab8a6986b243bffffffff02698214000000 00001976a914d4b7e4a5f8b3b4d89afc39ad74531d6708e8af7888ac80f93703000000001976a91 40a1b3859c100bbd92177938c799d03297da5eee988ac000000000100000001dcf94abec287724d 7cbdfe19e5ed7fa5c4aa2950157f4c231f57422ba3c393e5010000008b48304502210081e888523 22d90e5c7d864503ffac2f0148fa52271739fbfe92f96658c5716840220099454572acd0e0a7708 274d2f2d71aaf4604eeb22c3910935342d66aff9c1fa014104ec44f7c11bddb10d4941689d5c94a ed0f88dd55f5b38142328eee59c6d25a33fc4fbd129dce6a648727fd988edc53f6b73ab5925aec4 999ecca300c1c77f2931ffffffff02c3a70800000000001976a914304c36b86270a75090562da38 a15bb3ab242826b88acc04fef1e000000001976a91460f4a6c204fd2e7f1f535da41c7155608455 c1d088ac00000000010000000114f0a54bb5a3197e1cc5d342cc28d05c08fa8ec2ab45f00eb5a3d b77957de6b3000000008b48304502203a712cece97b4b69e8a607212e6e8537b5dcdd7deb9cb5c3 5d96606d04a6a16e02210086082cf2cdde9f0417893d5ae62fef9e62bb14c3a472f05c3c66fc28a ef772790141040db24bf551503b2cd4ecd6d8da5684329748e0086fadc87dcf958a9da201793d15 bc6018de42a4d1275953edbce3b482a116da370c027b6a8c1672980a98063dffffffff02b0390e0 8000000001976a914a8795c53847db5bf4a5d3807fedb3eef5c9bccf588ac20b709060000000019 76a914468e52c3d93ed577c227b754eee9db3844cd474a88ac00000000010000000144c407769c3 0d5685947b5aecebd2db1b54098f14fa651e0ef1f61fe7cc12aca000000008b48304502200ee575 c20bb42dd85e0921bedfdc34062e52173f3b7ce9a53ab042a572c477c302210097a57b3fec95f31 4c72195c822ae42cc2ad4e6d1ccb7f8a22a69f473037b6d960141040359fd7157ea38c8a87cf0df ca0834766ee46446990e2e1199f641b91e8c5351ce0ad2ec819951b82232b2c602467903ebedc7c 25987709bfcf26b213ec67e9effffffff02c3247000000000001976a9140902f0f585034c3a9ee9 a77901ed81bc7b33261488ac65a2a500000000001976a9145df00c1a8744abd22369f14172b6957 1ff0d189088ac000000000100000001ab9fbe5d2c33729b8f4fb78123cefb5d01623fdff5d49a6f bc81812bb120e5d9000000008b483045022100ce5f16d4dcfb1a2b3b45ae2e0b970a1673c666ecd bc32d4f106d8d31db6a0f65022003dac852c78e401e23b1526936502e55c55ad7c76af8c2e6250a 42094ceb4504014104e5b4d582e4dd25470c57652340590d640014ca8340fd9b4c5020ebf710b62 0cae4856eefa97d4ebfa050c97f1e99f33ac67163d4da6890f607293d767ca25d75ffffffff0255 e887a1010000001976a91426e488df8b4b9cd8d89dabe8d4fafdcf9ff1841088ac14229b4200000 0001976a91436c6a2d17eb1bcad973d413cc828de1e89de4e6c88ac000000000100000001726a71 f0f05329612b802c9728e116545bfb259804cb0efb5c458f009fdd1077000000008b48304502210 0f27a88f4302a1783d0525f0bae4b105be4b866d50db6cf3f1b124e2837a07fe80220033920870b bdda57660ec24dcdb6a4a50ad28adc38eefbcde5db77bbc467909901410414650f29e911944bd61 998f8de03a0481e5ef322356c066cddcc437377e7689c8ed24148393e753ba03dab553521d48cf8 94afa6aa2047f39911cf8b4e811015ffffffff02a04efc2c010000001976a914c2c1b41100f43c8 8ae693a538991fabf8c24026388ac000b6b1b000000001976a9148ba03b0cff1388cc902ee6aee8 742ca38c9a83ce88ac00000000
[02:57:40.568] Calculated hash: 00000000159c09e2c9e0fae14d9a4be6b1c59409a44a88e543c906100a6fb5e6
[02:57:40.568] Unhandled exception in upstream-work-submit-handler
java.lang.NullPointerException
at com.shadworld.bitcoin.p2p.BitcoinDualConnection.send(BitcoinDualConnection.java:151)
at com.shadworld.poolserver.source.merged.JsonRpcMergeMiningLocalWorkMakerDaemonHa ndler.doShareSubmit(JsonRpcMergeMiningLocalWorkMakerDaemonHandler.java:255)
at com.shadworld.poolserver.logging.ShareSubmitterThread.submitEntry(ShareSubmitterThread.java:176)
at com.shadworld.poolserver.logging.ShareSubmitterThread.clearPriorityQueue(ShareSubmitterThread.java:111)
at com.shadworld.poolserver.logging.ShareSubmitterThread.run(ShareSubmitterThread.java:57)
[02:57:43.636] 14 shares in 14.456 seconds. Current hashRate: 3.874 GH/s
[02:57:43.636] Submit Throttling on: false
[02:57:43.637] Doing database flush for Shares: 14
[02:57:43.642] Flushed 14 shares to DB in 5.0ms (2800/sec)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 14, 2011, 12:21:39 AM

geistgeld is not merged mining enabled. I believe namecoin is currently the only merged mining capable chain at the moment. Though there might be something happening to make devcoin compatible in the near future

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 14, 2011, 01:34:18 AM

bummer dude :(

I was able to get geistgeld to connect as a merged source on poolserverj, and geistgeld actually has a merged mining conf that comes with it, but I believe you that it is not compatible.

oh well,

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on November 14, 2011, 01:47:53 AM

Quote from: cablepair on November 14, 2011, 01:34:18 AM

geistgeld actually has a merged mining conf that comes with it, but I believe you that it is not compatible.

I could be wrong... Confirm it with Lolcust if it's compatible or not. If so I'll look into it.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: wannaBhacker on November 14, 2011, 04:33:02 PM

Has anyone tested this out for litecoin?

I've gotten it to work with bitcoin just fine. In fact, even had it work with namecoin merged mining. Looks like it is pushing good work for merged mining.

However, the Scrypt doesn't look like it works right. First problem I run into, is the payout address. It bombs automatically when I put in a litecoin address. It wants a bitcoin address regardless. I go ahead with a bitcoin address just to see if I can get it to work, and I get a no valid work found return back from both the miner and the web URL.

I've changed the hashing type to Scrypt. Change the name to litecoin. Updated RPC ports and usernames. Then set the merged chains to "". What did I miss? Or am I the first to try this on the Scrypt chains?

One other thing I tried was turning off local work generation. When I do that, it freaks out and says that difficulty target is bad.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 14, 2011, 06:52:33 PM

Quote from: shads on November 13, 2011, 12:22:37 PM

I have missed all of the messages Not sure why I have it set to notify.

Anyhow thanks I will pull Art's Namecoind can I use is bitcoind as well? Or should I use another bitcoind?
BTW: you do know MAKE -f make.unix bitcoind creates a bitcion daemon right?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 15, 2011, 09:32:13 PM

@pool operators using PoolserverJ,

Here is a feature request, i'am interested in and would like to hear your thoughts about it and if you think of using it too:
https://bitbucket.org/shadders/bitcoin-poolserverj/issue/12/estimated-block-reward-for-each-individual

Quote

In order to be capable as a pool operator to reward all pool member for block rewards, sooner or later transactions fees should be considered.

As the lifecycle of BItcoin and other forks continue, transaction fees on top of the block reward become more and more important.

Feature Request: Add the possibility to insert the block reward + transaction fees in a custom field in the share table for bitcoin and other forks (just like our_result_bitcoin, our_result_namecoin today).

The information should be match to the time, when the share was submitted.

The fees per block could be extracted from the merkle root (as far as i understood) or via the rpc command getmemorypool (which could result in a new bottleneck if performed for each share).

Here is shadders comment:

Quote

This should be fairly trivial to implement as the current block reward / tx fees are already calculated by the workmaker.

There is a question to resolve in what to do about aux chains. These will also have rewards + fees. This can be added as well but given the arbitrary number and unknown names of future block chains would have to be implemented in a similar way our_result_chainname.

Also important to note that the tx fees recorded at the time of share submission probably won't be the tx fees of the final block when it is found.

This could be useful if you want to credit your miner the right value per share, when the share was submitted.
For pps pools it will become more and more difficult how to credit a share if block reward will cut in a half multiple times in future. Same goes for other payout methods like DGM.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 17, 2011, 07:22:58 AM

Really no thoughts about variable block rewards?

Pool Ops should consider reading this:
https://bitcoil.co.il/pool_analysis.pdf (Chapter 7.2)
from https://bitcointalk.org/index.php?topic=32814.0

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: urstroyer on November 23, 2011, 09:25:21 PM

Bug Report for poolserverj-0.4.0rc7:

with localWorkGeneration=false i encountered this issue:

* Mining on aux Blockchain seems to be ignored (no longpolls on aux blockchain)

I don't know if you even want anyone use workmaker edition without workgeneration enabled, but the config parameter implies that it should work with workmaker disabled.

If you need more details, i'am happy to help :)

Cheers,

Chris

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 27, 2011, 12:07:41 AM

Quote from: DavinciJ15 on November 14, 2011, 06:52:33 PM

Quote from: shads on November 13, 2011, 12:22:37 PM

So I have finally gotten around to testing it with the ArtFroz version and it failed to work with coinbasing.

It finds the blocks but does not post them. If you want the logs let me know.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 28, 2011, 12:08:06 PM

Quote from: wannaBhacker on November 14, 2011, 04:33:02 PM

Did you give it a litecoin address from the local machine?

Also you may need to turn off local work generation and coinbasing for litecoin to work, I am not 100% sure but it does not work with all coins

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 29, 2011, 12:22:46 PM

Quote from: shads on November 13, 2011, 12:22:37 PM

Namecoind keeps shutting down any help with that will be appreciated.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 29, 2011, 12:57:40 PM

Davinci: just out of curiosity did you you compile namecoind normally? like with wxwigets and upnp and all that, or did you take any shortcuts?

Ive got a ArtForz binary I compiled on a i386 - if it will work on your machine try it out and see what happens

http://btcwebhost.com/files/namecoind

I installed wxwidgets and miniupnp manually and compiled namecoin with make -f makefile.unix

I currently have a pool up running poolservj 0.40 rc7 with bitcoind 0.50 artforz namecoind

I have 7 ghash pointed at it now - only did about 60k shares so far but we will see - hopefully I hit a mainnet block in the next couple days

btw I have to brag for shads, this machine is a p4 1.7 ghz with 256 mb of ram
and its running a mysql database, with poolserverj, bitcoind, namecoind and handeling 7ghash smooth as can be with relatively low server load!
woohoo! :)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on November 29, 2011, 02:08:53 PM

Quote from: cablepair on November 29, 2011, 12:57:40 PM

I did I am running bitcoind created by ArtFroz's Namecoin src

Code:

make -f makefile.unix bitcoind

Your Namecoind is 17MB did you run STRIP to remove unused code?

Can I assume its a 32bit version?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on November 29, 2011, 02:24:52 PM

yes 32 bit and no I did not strip it.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 04, 2011, 07:24:45 AM

Shadders? You still around? Just asking I haven't seen you in a minute, I hope all is well.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 08, 2011, 07:15:15 PM

Shadders if you are busy and can't help let me know I understand.

But if you have the time can you help me with a problem I am having?

Currently PSJ on a Amazon Large server is stalling and not responding during a LP and getting large numbers of partial shares. Below is the screen window where it slows down and does not respond to miners request for work.

Code:

[18:42:57.512] 31 shares in 10.816 seconds. Current hashRate: 11.464 GH/s
[18:42:57.513] Submit Throttling on: false
[18:42:57.513] Doing database flush for Shares: 31
[18:42:57.574] Flushed 31 shares to DB in 61.0ms (508/sec)
[18:42:57.580] TRACE[blockmon] Found partial block match.  Matches: [namecoin]. this: pseudo: 189042. lcd: 16725. lud: 16724. synced: true{bitcoin=[156657. lcd: 16725. lud: 16725], namecoin=[32385. lcd: 17162. lud: 16724]} other: pseudo: 189041. lcd: 1323369777581. lud: 1323369777581. synced: true{bitcoin=[156656. lcd: 310972. lud: 17161], namecoin=[32385. lcd: 17163. lud: 17161]}
[18:43:00.776] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 19921. lud: 19920. synced: true{bitcoin=[156657. lcd: 19921. lud: 19921], namecoin=[32385. lcd: 20358. lud: 19920]} other: pseudo: 189040. lcd: 1323369780777. lud: 1323369780777. synced: true{bitcoin=[156656. lcd: 314168. lud: 96294], namecoin=[32384. lcd: 96295. lud: 96294]}
[18:43:00.997] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 20142. lud: 20141. synced: true{bitcoin=[156657. lcd: 20142. lud: 20142], namecoin=[32385. lcd: 20579. lud: 20141]} other: pseudo: 189040. lcd: 1323369780998. lud: 1323369780998. synced: true{bitcoin=[156656. lcd: 314389. lud: 96515], namecoin=[32384. lcd: 96516. lud: 96515]}
[18:43:03.384] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 22529. lud: 22528. synced: true{bitcoin=[156657. lcd: 22529. lud: 22529], namecoin=[32385. lcd: 22966. lud: 22528]} other: pseudo: 189040. lcd: 1323369783385. lud: 1323369783385. synced: true{bitcoin=[156656. lcd: 316776. lud: 98902], namecoin=[32384. lcd: 98903. lud: 98902]}
[18:43:04.188] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 23333. lud: 23332. synced: true{bitcoin=[156657. lcd: 23333. lud: 23333], namecoin=[32385. lcd: 23770. lud: 23332]} other: pseudo: 189040. lcd: 1323369784189. lud: 1323369784189. synced: true{bitcoin=[156656. lcd: 317580. lud: 99706], namecoin=[32384. lcd: 99707. lud: 99706]}
[18:43:04.945] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 24090. lud: 24089. synced: true{bitcoin=[156657. lcd: 24090. lud: 24090], namecoin=[32385. lcd: 24527. lud: 24089]} other: pseudo: 189040. lcd: 1323369784946. lud: 1323369784946. synced: true{bitcoin=[156656. lcd: 318337. lud: 100463], namecoin=[32384. lcd: 100464. lud: 100463]}
[18:43:06.003] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 25147. lud: 25146. synced: true{bitcoin=[156657. lcd: 25148. lud: 25148], namecoin=[32385. lcd: 25585. lud: 25147]} other: pseudo: 189040. lcd: 1323369786004. lud: 1323369786004. synced: true{bitcoin=[156656. lcd: 319395. lud: 101521], namecoin=[32384. lcd: 101522. lud: 101521]}
[18:43:06.142] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 25287. lud: 25286. synced: true{bitcoin=[156657. lcd: 25287. lud: 25287], namecoin=[32385. lcd: 25724. lud: 25286]} other: pseudo: 189040. lcd: 1323369786143. lud: 1323369786143. synced: true{bitcoin=[156656. lcd: 319534. lud: 101660], namecoin=[32384. lcd: 101661. lud: 101660]}
[18:43:06.311] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 25456. lud: 25455. synced: true{bitcoin=[156657. lcd: 25456. lud: 25456], namecoin=[32385. lcd: 25893. lud: 25455]} other: pseudo: 189040. lcd: 1323369786312. lud: 1323369786312. synced: true{bitcoin=[156656. lcd: 319703. lud: 101829], namecoin=[32384. lcd: 101830. lud: 101829]}
[18:43:07.419] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 26564. lud: 26563. synced: true{bitcoin=[156657. lcd: 26564. lud: 26564], namecoin=[32385. lcd: 27001. lud: 26563]} other: pseudo: 189040. lcd: 1323369787420. lud: 1323369787420. synced: true{bitcoin=[156656. lcd: 320811. lud: 102937], namecoin=[32384. lcd: 102938. lud: 102937]}
[18:43:07.920] 10 shares in 10.408 seconds. Current hashRate: 3.843 GH/s
[18:43:07.920] Submit Throttling on: false
[18:43:07.920] Doing database flush for Shares: 10
[18:43:07.939] Flushed 10 shares to DB in 19.0ms (526/sec)
[18:43:10.015] TRACE[blockmon] Found partial block match.  Matches: []. this: pseudo: 189042. lcd: 29160. lud: 29159. synced: true{bitcoin=[156657. lcd: 29160. lud: 29160], namecoin=[32385. lcd: 29597. lud: 29159]} other: pseudo: 189040. lcd: 1323369790016. lud: 1323369790016. synced: true{bitcoin=[156656. lcd: 323407. lud: 105533], namecoin=[32384. lcd: 105534. lud: 105533]}

If you need more info or are too busy to help let me know.

Cheers

Davinci

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on December 08, 2011, 08:56:25 PM

I think he's busy with real life, he hasnt responded to my PM's last time online was 2 days ago...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 08, 2011, 10:23:51 PM

Quote from: cablepair on December 08, 2011, 08:56:25 PM

I think he's busy with real life, he hasnt responded to my PM's last time online was 2 days ago...

Yeah, he probably has a lot going on it's not like him to disappear.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: shads on December 09, 2011, 12:56:48 AM

Hi All,

Apologies for going AWOL for such a long time. I've had quite a few major personal matters to attend to and have barely been online. My last online date is probably deceiving as I have a tab permanently open so it refreshes whenever my browser starts...

It will probably be another couple of weeks before I can get refocussed on bitcoinworld again but I'm hoping to spend some serious time over the xmas break working out all the kinks in psj. In the meantime if you have any issues please collect as much log info as you can and I'll look at it when I'm back on deck.

On an unrelated note in a couple of weeks I'm going to be unemployed and looking for some new projects to take on. Be interested to hear from anyone that's looking for a dev partner for commercial bitcoin projects.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 09, 2011, 02:21:58 AM

Quote from: shads on December 09, 2011, 12:56:48 AM

Well I am glad to hear from you, I hope all of your problems will be solved and you are able to find employment in the bitcoin community your skills will help to add value to bitcoins.

Thanks for all your work and effort to date and I look forward to helping you fix up PSJ 0.4 for final release.

Cheers

Davinci

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on December 09, 2011, 01:41:21 PM

Davinci: what Namecoind did you end up using for your merged mining pool?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 09, 2011, 02:23:38 PM

Quote from: cablepair on December 09, 2011, 01:41:21 PM

Davinci: what Namecoind did you end up using for your merged mining pool?

Still using the same one I am making adjustments to PSJ to see if I can keep it from collapsing.

I've been using ArtFroz Nov 11th version with workmaker and the suggested patches all this time. It's still collapsing from time to time but now for the first time yesterday bitcoind has collapsed.

I tried upgrading to a large server on Amazon for several days and that's when bitcoind would randomly collapse and same with PSJ.

Now that I have moved back to micro server, PSJ and Bitcoind have been solid but namecoind is collapsing randomly.

I am not messing with PSJ settings to see if I can fix it.

Are you seeing the same issue?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on December 09, 2011, 03:19:32 PM

Don't have a problem with Namecoin, when they officially released Bitcoind 0.50 and I changed over to that the segmentation faults stopped

What patches are you using on the ArtForz fork?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: DavinciJ15 on December 09, 2011, 03:22:55 PM

Quote from: cablepair on December 09, 2011, 03:19:32 PM

Don't have a problem with Namecoin, when they officially released Bitcoind 0.50 and I changed over to that the segmentation faults stopped

What patches are you using on the ArtForz fork?

I have not switched to bitcoind 5 maybe I should switch.

Yes I am using ArtFroz fork.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: maxcarjuzaa on May 12, 2012, 05:23:35 PM

Trying to make this work with litecoin I am getting the floowong message. What do I have to do to make it work?

Thank you!
Max

Args - [2]: start ../conf-samples/local-daemon-mm.properties
PoolServerJ Service Starting Sat May 12 14:10:52 ART 2012
[14:11:00.745] Starting PoolServerJ v0.4.0-WM-b233-c-d5e730c5756c
[14:11:00.785] user.dir: /home/max/poolserverj-0.4.0rc2/bin
[14:11:00.794] Home path set to: /home/max/poolserverj-0.4.0rc2/bin/poolserverj.jar
[14:11:00.798] Home directory set from jar file location to: /home/max/poolserverj-0.4.0rc2
[14:11:00.890] Sever is set to testnet: false
[14:11:01.167] Adding donation target: chainName: namecoin donationAmount: 0.3 calc method: [% of total] addressUrl: http://poolserverj.org/meta/donations/ address: NFja75nNRHZYKtN9YQ6wHPQdmhzBEAmTAt
[14:11:01.185] Adding donation target: chainName: bitcoin donationAmount: 0.3 calc method: [% of total] addressUrl: http://poolserverj.org/meta/donations/ address: 1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq
[14:11:01.488] Wrote PID: 8219 to pidFile: /home/max/poolserverj-0.4.0rc2/tmp/poolserverj.pid
[14:11:02.878] Connecting to DB URL: jdbc:mysql://localhost:3306/poolserverj_native?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[14:11:06.383] Mapped parameter 1 to field 1 (remote_host)
[14:11:06.401] Mapped parameter 2 to field 2 (username)
[14:11:06.419] Mapped parameter 3 to field 3 (our_result)
[14:11:06.422] Mapped parameter 4 to field 4 (upstream_result)
[14:11:06.461] Mapped parameter 5 to field 5 (reason)
[14:11:06.481] Mapped parameter 6 to field 7 (time)
[14:11:06.497] Mapped parameter 7 to field 8 (source)
[14:11:06.515] Mapped parameter 8 to field 9 (block_num)
[14:11:06.530] Mapped parameter 9 to field 11 (useragent)
[14:11:06.555] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[14:11:06.577] Building Worker-authentication-engine: WorkerAuthenticator.class with extraParams: null
[14:11:07.027] Invalid payout address: LfR2QVzz5T7hcffbx6ZX5TL3e44HGV9Lth
com.google.bitcoin.core.AddressFormatException: Mismatched version number, trying to cross networks? 48 vs 0
   at com.google.bitcoin.core.Address.<init>(Address.java:57)
   at com.shadworld.poolserver.conf.Conf.configureSources(Conf.java:642)
   at com.shadworld.poolserver.conf.Conf.update(Conf.java:282)
   at com.shadworld.poolserver.conf.Conf.init(Conf.java:190)
   at com.shadworld.poolserver.conf.Conf.init(Conf.java:176)
   at com.shadworld.poolserver.PoolServer.<init>(PoolServer.java:114)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:98)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
   at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: cablepair on June 11, 2012, 09:48:29 PM

It does not work with litecoin

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on December 21, 2012, 07:42:49 PM

Guys, help me, please.
I have a problem with poolserverj:

Code:

Args - [2]: start ../conf/config.cfg 
PoolServerJ Service Starting Fri Dec 21 23:31:37 MSK 2012
[23:31:39.367] user.dir: /home/douson/general/poolserverj/bin
[23:31:39.369] Home path set to: /home/douson/general/poolserverj/bin/poolserverj.jar
[23:31:39.369] Home directory set from jar file location to: /home/douson/general/poolserverj
[23:31:39.512] Wrote PID: 19083 to pidFile: /home/douson/general/poolserverj/tmp/poolserverj.pid
[23:31:39.830] Connecting to DB URL: jdbc:mysql://localhost:3306/poolserverj_native?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[23:31:40.723] Mapped parameter 1 to field 1 (remote_host)
[23:31:40.723] Mapped parameter 2 to field 2 (username)
[23:31:40.723] Mapped parameter 3 to field 3 (our_result)
[23:31:40.724] Mapped parameter 4 to field 4 (upstream_result)
[23:31:40.724] Mapped parameter 5 to field 5 (reason)
[23:31:40.724] Mapped parameter 6 to field 7 (time)
[23:31:40.724] Mapped parameter 7 to field 8 (source)
[23:31:40.724] Mapped parameter 8 to field 9 (block_num)
[23:31:40.724] Mapped parameter 9 to field 11 (useragent)
[23:31:40.726] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[23:31:40.728] Building Worker-authentication-engine: AnyPasswordWorkerAuthenticator.class with extraParams: [true,false]
Failed to start
java.lang.NullPointerException
	at com.google.bitcoin.core.Base58.decodeToBigInteger(Base58.java:81)
	at com.google.bitcoin.core.Base58.decode(Base58.java:61)
	at com.google.bitcoin.core.Base58.decodeChecked(Base58.java:98)
	at com.google.bitcoin.core.VersionedChecksummedBytes.<init>(VersionedChecksummedBytes.java:34)
	at com.google.bitcoin.core.Address.<init>(Address.java:55)
	at com.shadworld.poolserver.conf.Conf.configureSources(Conf.java:596)
	at com.shadworld.poolserver.conf.Conf.update(Conf.java:279)
	at com.shadworld.poolserver.conf.Conf.init(Conf.java:189)
	at com.shadworld.poolserver.conf.Conf.init(Conf.java:175)
	at com.shadworld.poolserver.PoolServer.<init>(PoolServer.java:114)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:98)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
PoolServerJ Service Finished Fri Dec 21 23:31:40 MSK 2012

Where to look for a solution? How to run poolserverJ?

The command to start:

Code:

java -classpath poolserverj.jar:../lib/*:../lib/lib_non-maven/*:../lib/plugins com.shadworld.poolserver.servicelauncher.PoolServerService start ../conf/config.cfg

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on December 22, 2012, 08:19:03 PM

Now that's a mistake, after setting up the configuration file. ??? ??? ??? :'( :'(

Code:

Args - [2]: start ../conf/config.cfg 
PoolServerJ Service Starting Sun Dec 23 00:16:24 MSK 2012
[24:16:25.065] user.dir: /home/douson/general/poolserverj/bin
[24:16:25.066] Home path set to: /home/douson/general/poolserverj/bin/poolserverj.jar
[24:16:25.067] Home directory set from jar file location to: /home/douson/general/poolserverj
[24:16:25.094] Wrote PID: 3934 to pidFile: /home/douson/general/poolserverj/tmp/poolserverj.pid
[24:16:25.185] Connecting to DB URL: jdbc:mysql://localhost:3306/poolserverj_native?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[24:16:25.551] Mapped parameter 1 to field 1 (remote_host)
[24:16:25.552] Mapped parameter 2 to field 2 (username)
[24:16:25.552] Mapped parameter 3 to field 3 (our_result)
[24:16:25.552] Mapped parameter 4 to field 4 (upstream_result)
[24:16:25.552] Mapped parameter 5 to field 5 (reason)
[24:16:25.552] Mapped parameter 6 to field 7 (time)
[24:16:25.553] Mapped parameter 7 to field 8 (source)
[24:16:25.553] Mapped parameter 8 to field 9 (block_num)
[24:16:25.553] Mapped parameter 9 to field 11 (useragent)
[24:16:25.555] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[24:16:25.556] Building Worker-authentication-engine: WorkerAuthenticator.class with extraParams: null
1090 [main] INFO org.eclipse.jetty.util.log - jetty-7.4.0.v20110414
1167 [main] INFO org.eclipse.jetty.util.log - started o.e.j.s.ServletContextHandler{/,null}
1332 [main] WARN org.eclipse.jetty.util.log - FAILED SelectChannelConnector@0.0.0.0:8332 FAILED: java.net.BindException: Address already in use
1332 [main] WARN org.eclipse.jetty.util.log - FAILED org.eclipse.jetty.server.Server@48ea48be: java.net.BindException: Address already in use
java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:172)
	at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:304)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:250)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:58)
	at org.eclipse.jetty.server.Server.doStart(Server.java:264)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:58)
	at com.shadworld.poolserver.PoolServer.startHttpListenersWithServlets(PoolServer.java:550)
	at com.shadworld.poolserver.PoolServer.start(PoolServer.java:257)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:99)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
[24:16:26.008] Shutting down poolserver... 
[24:16:26.008] Flushing cached shares...
[24:16:26.009] Flush shares cache complete...
[24:16:26.009] Waiting to complete upstream share submits...
[24:16:26.012] Finished upstream submits...
[24:16:26.012] Flushing final shares...
[24:16:26.012] All share submits flushed...
[24:16:26.012] Waiting for threads to die...
[24:16:26.013] 0 shares in 1 356 207 360 seconds. Current hashRate: 0 GH/s
[24:16:26.013] Submit Throttling on: false
[24:16:26.015] Dumping workmap to file: /home/douson/general/poolserverj/tmp/workmap-8332.bin
1347 [Thread-0] INFO org.eclipse.jetty.util.log - Graceful shutdown SelectChannelConnector@0.0.0.0:8332 FAILED
1351 [Thread-0] INFO org.eclipse.jetty.util.log - Graceful shutdown o.e.j.s.ServletContextHandler{/,null}
[24:16:26.306] Shutting down Web Server...
[24:16:26.409] Closed 0 longpoll connections in 1ms
6353 [Thread-0] INFO org.eclipse.jetty.util.log - stopped o.e.j.s.ServletContextHandler{/,null}
[24:16:31.078] Shutdown complete...

Help, please!!!!!!!!!!

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Pontius on December 23, 2012, 03:56:09 PM

Quote

[...]
1332 [main] WARN org.eclipse.jetty.util.log - FAILED SelectChannelConnector@0.0.0.0:8332 FAILED: java.net.BindException: Address already in use
1332 [main] WARN org.eclipse.jetty.util.log - FAILED org.eclipse.jetty.server.Server@48ea48be: java.net.BindException: Address already in use
java.net.BindException: Address already in use
[...]

Some other process (probably 'bitcoind') is already listening to 0.0.0.0:8332. Reconfigure either bitcoind or psj to a different port...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on December 23, 2012, 05:29:01 PM

Fixed port, and came running lines:

Code:

Args - [2]: start ../conf/config.cfg 
PoolServerJ Service Starting Sun Dec 23 21:26:45 MSK 2012
[21:26:45.974] Starting PoolServerJ v0.4.0-WM-b233-c-d5e730c5756c
[21:26:45.975] user.dir: /home/douson/general/poolserverj/bin
[21:26:45.975] Home path set to: /home/douson/general/poolserverj/bin/poolserverj.jar
[21:26:45.975] Home directory set from jar file location to: /home/douson/general/poolserverj
[21:26:45.981] Sever is set to testnet: false
[21:26:46.000] Wrote PID: 3711 to pidFile: /home/douson/general/poolserverj/tmp/poolserverj.pid
[21:26:46.090] Connecting to DB URL: jdbc:mysql://localhost:3306/poolserverj_native?allowMultiQueries=true&zeroDateTimeBehavior=round&dumpQueriesOnException=true&dumpMetadataOnColumnNotFound=true&useCompression=true&autoReconnect=true&rewriteBatchedStatements=true
[21:26:46.455] Mapped parameter 1 to field 1 (remote_host)
[21:26:46.456] Mapped parameter 2 to field 2 (username)
[21:26:46.456] Mapped parameter 3 to field 3 (our_result)
[21:26:46.456] Mapped parameter 4 to field 4 (upstream_result)
[21:26:46.456] Mapped parameter 5 to field 5 (reason)
[21:26:46.456] Mapped parameter 6 to field 7 (time)
[21:26:46.457] Mapped parameter 7 to field 8 (source)
[21:26:46.457] Mapped parameter 8 to field 9 (block_num)
[21:26:46.457] Mapped parameter 9 to field 11 (useragent)
[21:26:46.460] Building Shares-DB-flush-engine: DefaultPreparedStatementSharesDBFlushEngine.class with extraParams: []
[21:26:46.461] Building Worker-authentication-engine: WorkerAuthenticator.class with extraParams: null
1070 [main] INFO org.eclipse.jetty.util.log - jetty-7.4.0.v20110414
1235 [main] INFO org.eclipse.jetty.util.log - started o.e.j.s.ServletContextHandler{/,null}
1258 [main] WARN org.eclipse.jetty.util.log - FAILED SelectChannelConnector@0.0.0.0:8337 FAILED: java.net.BindException: Address already in use
1259 [main] WARN org.eclipse.jetty.util.log - FAILED org.eclipse.jetty.server.Server@7cbe41ec: java.net.BindException: Address already in use
java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:172)
	at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:304)
	at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:250)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:58)
	at org.eclipse.jetty.server.Server.doStart(Server.java:264)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:58)
	at com.shadworld.poolserver.PoolServer.startHttpListenersWithServlets(PoolServer.java:550)
	at com.shadworld.poolserver.PoolServer.start(PoolServer.java:257)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.start(PoolServerService.java:99)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.windowsService(PoolServerService.java:58)
	at com.shadworld.poolserver.servicelauncher.PoolServerService.main(PoolServerService.java:28)
1264 [Thread-0] INFO org.eclipse.jetty.util.log - Graceful shutdown SelectChannelConnector@0.0.0.0:8337 FAILED
1265 [Thread-0] INFO org.eclipse.jetty.util.log - Graceful shutdown o.e.j.s.ServletContextHandler{/,null}
[21:26:46.827] Shutting down poolserver... 
[21:26:46.827] Flushing cached shares...
[21:26:46.827] Flush shares cache complete...
[21:26:46.828] Waiting to complete upstream share submits...
[21:26:46.828] Finished upstream submits...
[21:26:46.828] Flushing final shares...
[21:26:46.829] 0 shares in 1 356 283 648 seconds. Current hashRate: 0 GH/s
[21:26:46.829] Submit Throttling on: false
[21:26:46.830] All share submits flushed...
[21:26:46.830] Waiting for threads to die...
[21:26:46.831] This error may indicate your bitcoin daemon was not contactable. Check it is running and you have entered the correct host:port for the bitcoin protocol interface NOT the json-rpc interface.
java.lang.NullPointerException
	at com.shadworld.bitcoin.p2p.BitcoinDualConnection.shutdown(BitcoinDualConnection.java:133)
	at com.shadworld.poolserver.source.merged.JsonRpcMergeMiningLocalWorkMakerDaemonHandler.shutdown(JsonRpcMergeMiningLocalWorkMakerDaemonHandler.java:146)
	at com.shadworld.poolserver.source.WorkSource.shutdown(WorkSource.java:190)
	at com.shadworld.poolserver.WorkProxy.shutdown(WorkProxy.java:923)
	at com.shadworld.poolserver.PoolServer.shutdown(PoolServer.java:620)
	at com.shadworld.poolserver.PoolServer$1.run(PoolServer.java:252)
[21:26:46.833] This error may indicate your bitcoin daemon was not contactable. Check it is running and you have entered the correct host:port for the bitcoin protocol interface NOT the json-rpc interface.
java.lang.NullPointerException
	at com.shadworld.bitcoin.p2p.BitcoinDualConnection.shutdown(BitcoinDualConnection.java:141)
	at com.shadworld.poolserver.source.merged.JsonRpcMergeMiningLocalWorkMakerDaemonHandler.shutdown(JsonRpcMergeMiningLocalWorkMakerDaemonHandler.java:146)
	at com.shadworld.poolserver.source.WorkSource.shutdown(WorkSource.java:190)
	at com.shadworld.poolserver.WorkProxy.shutdown(WorkProxy.java:923)
	at com.shadworld.poolserver.PoolServer.shutdown(PoolServer.java:620)
	at com.shadworld.poolserver.PoolServer$1.run(PoolServer.java:252)
[21:26:46.835] Dumping workmap to file: /home/douson/general/poolserverj/tmp/workmap-8337.bin
[21:26:47.149] Shutting down Web Server...
[21:26:47.251] Closed 0 longpoll connections in 1ms
6267 [Thread-0] INFO org.eclipse.jetty.util.log - stopped o.e.j.s.ServletContextHandler{/,null}
[21:26:51.880] Shutdown complete...

I enter my username and password, click

Code:

http://127.0.0.1:8337/?method=fireblockchange

Result

Code:

{"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}

What am I doing wrong?
??? ???

and Can I get a working config file???

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Graet on December 25, 2012, 04:58:40 AM

<quote>[21:26:46.833] This error may indicate your bitcoin daemon was not contactable. Check it is running and you have entered the correct host:port for the bitcoin protocol interface NOT the json-rpc interface.
java.lang.NullPointerException</quote>

you need to fix the port thing

which version of bitcoind are you using?

why are you trying to use old and unmaintained software?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on December 25, 2012, 05:23:57 AM

Quote

why are you trying to use old and unmaintained software?

I would be very grateful for the best software. Tell me, please!

Quote

which version of bitcoind are you using?

OS: Scientific Linux
Bitcoind: I'm using version 0.7.2.
But, I read that this version does not work well without poolserverJ patch. It's true?

Quote

you need to fix the port thing

Tell me how to do it correctly?

Thank you very much for your help. Thanks in advance.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Graet on December 25, 2012, 05:41:46 AM

Quote from: Vyacheslav on December 25, 2012, 05:23:57 AM

Quote

why are you trying to use old and unmaintained software?

I would be very grateful for the best software. Tell me, please!

Quote

which version of bitcoind are you using?

OS: Scientific Linux
Bitcoind: I'm using version 0.7.2.
But, I read that this version does not work well without poolserverJ patch. It's true?

Quote

you need to fix the port thing

Tell me how to do it correctly?

Thank you very much for your help. Thanks in advance.

stratum is the best pool software at the moment IMO

there is a patch for poolserverj and 0.7.x? - sorry I wasn't aware of that, afaik no updates have been made to poolserverj for over a year

someone already explained how to fix the port issue

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on December 28, 2012, 07:45:58 AM

I started the server. There was one error now!

Code:

Retrieving worker from database: testuser
[11:28:17.550] Error attempting to retrieve user from database.
java.sql.SQLException: SQL String can not be NULL
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927)

Create a user in the database:

Code:

INSERT INTO `pool_worker` (`username`, `password`) VALUES ('testuser', 'test');

In a database table:

https://dl.dropbox.com/u/7219599/userbd.PNG

What is the correct query to create a user? If my request is not correct...

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: RoboCoder on January 04, 2013, 06:38:19 PM

Quote from: Vyacheslav on December 28, 2012, 07:45:58 AM

I started the server. There was one error now!

Code:

Retrieving worker from database: testuser
[11:28:17.550] Error attempting to retrieve user from database.
java.sql.SQLException: SQL String can not be NULL
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927)

Create a user in the database:

Code:

INSERT INTO `pool_worker` (`username`, `password`) VALUES ('testuser', 'test');

In a database table:

https://dl.dropbox.com/u/7219599/userbd.PNG

What is the correct query to create a user? If my request is not correct...

Did you continue with the .7 release? I have the same error about not being able to contact the bitcoin protocol port not the json-rpc: did changing the bitcoind to an older version fix the problem?

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: Vyacheslav on January 04, 2013, 06:48:19 PM

Quote from: RoboCoder on January 04, 2013, 06:38:19 PM

Did you continue with the .7 release? I have the same error about not being able to contact the bitcoin protocol port not the json-rpc: did changing the bitcoind to an older version fix the problem?

I have not solved the problem.
I do not know how to fix.

Title: Re: [ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1
Post by: RoboCoder on January 04, 2013, 06:56:42 PM

Quote from: Vyacheslav on January 04, 2013, 06:48:19 PM

Quote from: RoboCoder on January 04, 2013, 06:38:19 PM

Did you continue with the .7 release? I have the same error about not being able to contact the bitcoin protocol port not the json-rpc: did changing the bitcoind to an older version fix the problem?

I have not solved the problem.
I do not know how to fix.

If you are talking about the user issue - the only different i see in yours from mine is that i matched the id column in the associated userid - which of course doesnt jive with the error message. You might also try deleting that record and doing an insert and define all 4 fields. I personally just used dbForge and added the records via the client interface. I should note that i am running on windows 2008 not *nix..

Bitcoin Forum

Bitcoin => Mining => Topic started by: shads on November 08, 2011, 05:51:01 AM