[ANNOUNCE] Poolserverj WORKMAKER EDITION RELEASED - 0.4.0rc1

[Retard]

Im testing ,

looks good at time.

[1713475571]

1713475571

[1713475571]

1713475571

[1713475571]

1713475571

[shads]

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.

[cablepair]

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

I will send donation now, very good work

[shads]

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.

[Retard]

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


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

[cablepair]

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!

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)

[shads]

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

[cablepair]

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,

[shads]

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.

[wannaBhacker]

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.

[DavinciJ15]

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.

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?

[urstroyer]

@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

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:

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.

[urstroyer]

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

[urstroyer]

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

[DavinciJ15]

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.

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?

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.

[cablepair]

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.

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

[DavinciJ15]

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.

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

[cablepair]

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!

[DavinciJ15]

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!

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?

[cablepair]

yes 32 bit and no I did not strip it.