any chance to add native support for Stratum mining protocol? http://mining.bitcoin.cz/stratum-mining
There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.
The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.
Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.
Let me know what you think about it!
Until ckolivas returns and gives his opinion, which may be completely different to mine ...
As an aside ... I will repeat comments I've made (here and elsewhere) about this generic idea, and add to them:
Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.
This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.
I'm certainly not saying yes or no about implementing getmemorypool (which is where your idea actually comes from) however, noting the implications of it, I've wondered if anyone has considered them in detail (I've also had a quick click on the web link and the very first item has an issue in my opinion - the pool deciding when the miner should be given work ...)
I will also make comment on performance:
There are a bunch on simple improvements to the getwork protocol that could easily extend the life of the current protocol.
Simplest one would be reference information so that a share returned only requires 3 things: reference, nonce, time
and the getwork would only need to send: reference, version, prevblk, merkle, time, diff
There is a LOT of blank space in the getwork data - so comparing sizes is rather meaningless unless the blanks were removed ...
LP sux due to it's design (was Tycho drunk that night he designed it?) - and there are other options already available.
The roll-n-time hack only exists coz the bitcoin devs are wimps and can't do a hard fork (since they can't even smoothly do a soft fork) and fix the MSDOS restriction of the nonce size.
A nonce size increase would mean that the timing of when the miner would talk to the pool (or the local "Stratum" program) would only be at a frequency decided necessary to include new transactions or maybe also via notification due to a large fee transaction.
The simple problem is that with any such protocol using the current nonce size, the miner MUST talk to the work source (be it part of the same program, a local "Stratum" program, or a pool) every ~4billion hashes - which is not a big number when the miner could EASILY have multiple TerraHash/second - i.e. plug in a few if BFL's so called soon to come 1TH/s devices
I seriously don't understand why anyone coming up with these similar 'Stratum' ideas doesn't spot the obvious problem there, that is directly caused by the nonce size.
Moving to using an extra-nonce in the coinbase transaction is again only needed since the block header nonce is too small - yet there is PLENTY of space to increase it's size in the sha256 empty space ... to 128 bits without any issue.
The miner would never run out of work, before it needs to consider a work change, with a 128bit nonce (well maybe not for a few years at least
Using the 'extra-nonce' idea also means that the mining software is spending a LOT of unnecessary effort talking to the work source (and the work source is doing way more work than necessary) that a larger nonce size would remove.
Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)
Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?