No need to ask permission to modify psj.  It's GPL.  Earlier versions were no-derivs creative commons license but that's long gone.  However, I don't think you'll need to. Take a look at the very end of the sample properties file.  There is actually an option to set difficulty though no one's ever used it in production as far as I know.  I would recommend after setting you do a manual getwork and inspect the target to ensure the endianess is correct.

I don't know anything about litecoin but psj has been successfully used on several alt chains.  The only real requirement is that the alt chain uses the same hashing algorithm as bitcoin, if so poolserverj won't know the difference and will happily do it's thing.

One this to watch with alt chains though is whether or not they've got the duplicate work bug.  Have search back in this thread for an explanation of it...

submit work should be a lot more than 40 bytes... Unless you mean outbound...

Getwork could be reduced to about 40 bytes + maybe another 40 for tcp overhead with a proper differential binary protocol.  80/640 = 88% reduction.  I'm thinking of working on that as part of the next phase of poolserverj development but I'd be interested to hear if bandwidth costs really are an issue for pool ops... If so just have to hope some miner devs will step up and implement the client side of it.

basically first request contains all the stuff in a normal getwork (though in binary) except midstate which is redundant.  Subsequent requests only contain a new merkle root and timestamp.  These are the only fields that actually change except at longpoll time.

hmm the very 1st assertion in the article:


And it's a blatant lie.  I'd prefer to put it down to stupidity rather than outright deception but I have trouble believing someone who's key marketing feature is 51% immunity could get this so completely wrong.

Either the stupid is off the scale or the deception is blatant.

Well I just don't think encouraging/facilitating tiny payouts is a good idea... perhaps this is the way to go: "Maybe 1% of the current block size limit? That gives 294 outputs max at 1 MB (the current hard-coded block size limit)"

It's more tricky for pool ops to calculate but it is a sensible number.

Well I can see two approaches to determining limit.  Both have issues but just because it's tricky to enforce a limit sensibly isn't a good reason to allow open slather...

1/ Tx outpoint size is relatively constant.  Yes it can vary but for 99% of use cases it will the same type of script which is the same length.  So from simple easy to enfore rule that would probably be the better option.  I notice eligius already has some notion of a payout queue and I thought that might be somehow related to this issue.  I was quite suprised when I started looking a eligius coinbases to find the number of outputs was always far far less than what I'd guess yr total miners would be.  That's actually what got me thinking about this as a potential problem.  When I saw that I thought you were limiting it for that very reason.

2/ min tx value would be easier from a pool ops point of view.  And whilst the size of the outputs would be more variable it would at least prevent extreme accidental abuse.

Those are the options I can think of... not sure which is the best or if there's a better one or if I'm even worrying about a non-issue.  Hoping someone else will step up with an opinion...

True anyone could create a monster coinbase transaction if they had the knowledge to construct a block from scratch and feed it into the network via p2p protocol.  But if you knew enough to do that you'd probably know why it's a bad idea.  A simple command line switch doesn't require any real knowledge of the network to use successfully and that's where the danger lies.  A relatively technically unskilled pool op decides to payout every single miner on every won block.  This is quite feasible and without any enforcement it just makes the problem accessible to people more likely to make the mistake.


And those blocks without magic prefix are accepted by the rest of the nmc network?  If so that's my concern dealt with.

*If* a reasonable limit on coinbase outputs could be added then for what it's worth I'd be happy to add my vote in favour on the change.  Without said limits then my vote is in favour of the 'setworkaux' part of the change only.

I've only got two concerns left with this patch.  Luke's done some good doco for both parts of it.  And now that he's explained how you'd use a bit better I can see this becoming an eventual replacements for most of vinced's implementation.   It is a much cleaner way in the long run.

The remain concerns are:  Does the -coinbase <cmd> enforce either a minimum tx output value or a max number of tx outputs?  If not it should.  The primary use case for this for pools to payout their miners and have invalid blocks dealt with automagically.  It there are no limits it's only a matter of time before some pools start paying out tiny balances to masses of miners.  This could bloat the coinbase a lot unless I'm missing something. 

My second concern is that Luke has made the following comment in the wiki:


As far as I can see this patch doesn't deal with validation of the aux blocks.  Presumably this will be left to vinced's original code as you'd require an update to all namecoin miners to alter it's validation rules.  So the question is, will the absence of OP_2, 0xfa, 0xbe, 'm', 'm' before the aux header prevent vinced's validation from working?  If so then the rpc call should check this and return an error if it doesn't.

This is not required for the current merged mining implementation.  In fact it doesn't allow you to tell bitcoind what to put into the coinbase.  It's a read only operation.  I see where you're coming from but blocking this feature is not to going to stop people generating blocks with their own data.  There's nothing to stop someone collecting transactions by listening to the p2p protocol and generating their blocks that way.  This gives the opportunity to leverage code in bitcoind i.e. you can assume what's contained in the response of getmemorypool has passed bitcoind's validations but there's nothing stopping you from implementing this yourself or even accepting transactions with different criteria.

At the end of the day your concerns can't be addressed by blocking features in one client.  They need to be addressed at the protocol level.  If the protocol and therefore the majority of block generating clients define > n bytes in coinbase to be invalid then that's the way it is.  Simply preventing one client from generating blocks like that doesn't stop anyone else from doing it.

If you wanted to block merged mining for example all you'd have to do is create a patch to reject blocks with more than 39 bytes of arbitrary data in the coinbase.  Then get enough pools to represent 51% to run the patch.  It's not part of the official client but it becomes the defacto protocol by virtue of adoption.

Fair call...  A pool op would still have plausible deniability.  You can insert any old junk into the coinbase.   Correct me if I'm wrong but the MM specific stuff in the coinbase is the merkle root + tree size + nonce so with a random nonce the only real signature is the tree size and length of the data.

However, plausible deniability is probably largely academic since any pool up with unexplained data in their coinbases will no doubt come under suspicion now.

BTW this looks wrong to me: coinbase":"045dee091a03ac8701522cfabe6d6defb6519b6439e5852d2cdba258fe21438204f3eb6f69001fc d74e884ee87482b0100000000000000"

it indicates a tree size of 0?

Actually I'm implementing a work generator module that can either run embedded inside poolserverj or as a standalone.  The reason for the latter is that psj can get pretty busy with other things as well so you may still want to spread that load across two servers... The standalone will not use rpc.  It will simply stream work to psj in a compact binary format and psj controls the flow by sending stop/start signals.

The only way I can think you can detect it is after the parent chain has made a block... if the aux chain has a lower difficulty there should be a corresponding block.  Both block contain the data needed to confirm they linked.  However if a pool op wanted to hide it all they'd have to do is when they won a bitcoin block don't send the solution to the aux chain.  Then there's no link... They lose 1 block on the aux chain but they get all the aux chain blocks that meet aux difficulty but not bitcoin difficulty, which is most of the.

rofl...

sig

|
V

just the address in my sig is fine...

Just uploading rev .02 atm.  Found a deadlock in the work submit thread.  There's some awfully convoluted syncing that has to go on there.

about 6 mins to go on my lightning internet connection.

also, recommend that you set 'forceAllSubmitsUpstream' until it's proven that it detects winning shares.  There will be a log file created in yr launch directory called 'real-share-submits.log' that tracks the progress of a suspected winning share through the server and gives the info we need to prove it's going to work without the force option switched on.

If you have corresponding bitcoin and aux chain blocks you can prove they are connected.  All you'd need to do is wait for a pool to find a bitcoin block then see if an alt chain had one about the same time.  Do a bit of cryptoacrobatics and you've got yr proof.

The way it could be hidden is if when you win a block on high diff chain don't submit the work to lower diff chain.  You lose the alt chain's block but then there's no link.  Just keep all the alt chain blocks that solve for the alt chain but not the main chain.

Committed...

Well we may have to wait a while to decide if that counts as working.  Of course I can actually test if winning blocks are accepted without winning one on my 50MH rig.

been going at this damn thing for 6 hrs straight now.  I remember why I've been putting it off for so long.

BTW I told Davinci that I wouldn't release this publicly for at least a week after he got it which I think is fair given the hefty bounty he's posted.  However he generously declined the offer and requested I make it available to everyone immediately so if you do use it please consider making a donation to Davinci because I certainly wouldn't have gotten off my lazy arse to finish if he hadn't dangled the carrot in front of me.

You can't get answers to your questions.  And you can't figure it out because there is no documented spec and interpreting the source code leaves many ambiguities.

It's quite possible (I'd say even likely) there's something wrong with the way solutions are being submitted to the NMC daemon.  It's hideously complex process to submit and there's plenty of place where it could go wrong.

k well I better stop playing with merkle trees and get some sleep then

18hrs... I gotta sleep