That's fantastic cablepair!  I'll put a link to it on the PSJ site and in the other thread. 

My only suggestion is that you point people to download page rather than linking to the specific versions.  I leave the old versions on the server so those links will be valid long after the psj version has incremented.

I want to purchase some goods from a US merchant.  The good are not illegal but they are on the paypal shitlist so he can't use them.  His current options are western union, moneygram etc...

If I'm going to pay $20 for a WU money order and deal with the delay of sending it to him and him having to cash it, I'd much rather pay a premium to cover his currency risk and pay in bitcoins.  But it seems a good opportunity to upsell him in accepting bitcoins as a normal payment method.

Now this guy has never heard of bitcoins and probably has little interest in them beyond the ability to accept foreign payments quickly.  So what I imagine he would want from a solution would something like this:

He provides a bitcoin address for payment, the solution calculates bitcoin value based on exchange rate + small risk premium, once bitcoin is received it's immediately put on market and converted to USD.

Is there a merchant solution that does all this?  Particularly the last part as his key interest will be fast cross border payments into USD.

The differences are all explained here: https://bitcointalk.org/index.php?topic=51226.0

It runs with vanilla bitcoin 0.5.0.  I've seen the rpc thread crash in bitcoind a few times in my test environment but I've never heard of it happening in a production environment so it could just be something peculiar to my setup.  I do put my poor little bitcoind through some pretty horrible contortions that probably don't happen on a normal pool setup.

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

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

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.

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.

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.

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

and he loves you for it... not often I get donations direct from miners.  I guess psj is kind of below the radar for most miners which is kinda funny since it's actually their point of contact with the pool.

If that's the case the you might be interested in the new column mappings that are used in the latest version.  Previously it was built in a way such that if you wanted data field 9 included in your query you had to 1-8.  Which was very restrictive and inneficient if you happened to only need columns 1,2 and 9.  for example.

Now you can provide a mapping string which allows you to pick and choose data fields and map them to a position in your query.  This has opened up the possibility of adding any number of additional data fields and dynamic calculuations.  The current 'menu' includes:


As well as per chain our_result_<chainname>.  You can expect this to expand considerably in the near future.

adding new ones is now trivial.  e.g. there's a number of stats that have been tracked internally by workers for some time, these can now be exposed to the DB engine easily.

Obviously if you want to do additional calculations for DGM inside the server you can't really avoid building from source.  Although it's no longer as daunting as it once was.  I published this step-by-step to getting a build environment ready a couple of weeks ago: http://poolserverj.org/documentation/guide-to-setting-up-poolserverj-in-eclipse-3-7/

I don't know a lot about DGM aside from what it stands for but if you can give a rundown on what you need to do I can probably tell you where the best place in the code would be to achieve it.  The DB API itself has an awful lot of data exposed to it.  In most cases it's a single method that needs modifying.

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.

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


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.

Catfish I didn't follow the Ars issues in closely because I was flat out with building merged mining support at the time.  But I would like to set a few things straight.

Firstly BT changed to PSJ for precisely those reasons of instability that Ars was experiencing with pushpool.  Whether it improved greatly or not I'm not sure, I know the stale rate dropped dramatically, however, the miner load compared to the server spec was pretty close to the limit for both PSJ and pushpool at the time.  I'll point out that BTC Guild was running double the hashrate on a single server using the same version of PSJ and had no stability or memory leaking issues.  Admittedly it was a higher hardware spec.

I will certainly concede that that the merged mining version of PSJ was wildly unstable for quite a period though it was clearly tagged as pre-alpha.  That was partly due to the fact I was offered a huge bounty for getting it out by a certain deadline so I did things in ways I would have preferred not to.  The new WorkMaker edition has only been released for a few days and despite the expected teething troubles is working in production at high loads with massively reduced resource usage.  It now several times faster than pushpool (and the 0.3.0 version of PSJ) on every metric and more than an order of magnitude faster on some.  Not to mention having some unique features specifically aimed at stability, i.e. able to continue operating seamlessly if the database goes down.

My point is, don't write it off due the Ars experience.  The evidence suggests the problems were not PSJ specific and unfortunately due to being so flat out with merged mining development I was not able to get as involved in working out the Ars issues as I would have liked.  I suspect if BT tried the new version and had the time to iron it out to to a working config he'd find a lot of his problems which are probably related to near-limit CPU usage would go away.  If stability is the prime directive of EMC then it is probably premature to look at PSJ workmaker edition due to it's very recent release and some known bugs. 

All of the issues reported so far with workmaker edition are typical  'dev forgot to account for this weird combo of config settings' none of them are stability related.  In fact PSJ has all sorts of code in it to deal with unexpected circumstance.  e.g. an aux daemon going down means the pool will revert to non-merged-mining mode.  Bad config combos will usually result in the server refusing to start with a warning message rather than allowing it continue into a potential fail scenario.  Failures in internal components are usually detected and trigger a restart of them if they are internal or a failback mode if they are external.  Of course it will go through periods of less than ideal stability during heavy innovation but overall it is designed and geared toward being able to achieve stability and has a good track record of that.

What's wrong with this picture? :


try

also set localCoinbasing=false

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

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

try source.local.1.localWorkGeneration=true

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

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

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

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