WhiteShum, honestly, I'm sure there're many bugs in Diablo. All rejected should be logged in proxy (although I agree that the proxy log is quite verbose at this moment). What do you see there? If you see accepted on the pool and accepted in the proxy, then it's definitely just Diablo failing in rejection reporting.

I've tested all stuff with cgminer, poclbm and ufasoft and no one of these miners have such problems.

I'm not surprised .


Well, unfortunately, this is possible on some backends. That's why I want to switch to Stratum as soon as possible. Next week there'll be already native support in some miners, so I hope that more people switch transparently.

In the last phase, I'll switch off the old pool and start bunch of proxies to Stratum there instead.



Excellent!

Yes, I think that protocol itself is stable. I'll just add some additional methods for managing connections, like client.reconnect() or so, but it's not directly related to protocol core and you can implement it "as is".

I'm just not sure how you can implement persistent connections with PHP. Maybe running "official" python proxy and implement your software to talk to it locally would be smarter (and easier) choice.

Did you tried to install dependencies by "sudo easy_install twisted stratum" ? I'll have time to dig into and release some fix only on Monday. But this is quite specific bug happening on your system and that command above should help you.

Basically you can run any getwork miner towards stratum proxy, including phoenix. So there's no reason to move to other miner if you'll have some monitoring scripts. Also I'll work on stratum patch for Phoenix 2 soon.

Let's celebrate! Block of round #13852 has been finished by Stratum pool! And the founder iiiis.... no digital, it's not you :-(.

Blocks done by Stratum can be easily identified on blockchain.info; they're "Relayed by slush" and have "Version 2".

Two hours ago my Stratum-powered pool core mined its first block: http://blockchain.info/block/0000000000000322b90111260dcbb877c62c14e672c23a99a86ca444dc5525ee?site=slush

This is a confirmation that opensource stack which I provided builds blocks which are accepted by main chain.

I just released new version of mining proxy, version 0.5.0. Older versions still works nicely, this adds some few features:

* Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.

* Added "--no-midstate" parameter. When used, proxy won't generate "midstate" field in the getwork response. Some old miners and Diablo still requires this field, but modern miners like poclbm/cgminer can generate midstate ourselves and in much faster way. So if you're using these miners and want to save a bit of CPU time, this argument is just for you. It speeds up getwork creation twice.

In the near future I'll publish complete API documentation of such commands like client.reconnect(), client.get_version() or mining.get_hashrate(). Stay tuned :-).

I just released new version of mining proxy, version 0.5.0. Older versions still works nicely, this adds some few features:

* Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.

* Added "--no-midstate" parameter. When used, proxy won't generate "midstate" field in the getwork response. Some old miners and Diablo still requires this field, but modern miners like poclbm/cgminer can generate midstate ourselves and in much faster way. So if you're using these miners and want to save a bit of CPU time, this argument is just for you. It speeds up getwork creation twice.

digital: The luck of whole bitcoin network in the last hour is quite interesting .

I just added Stratum hashrate indicator to Stats page. We're already on 20 Ghash/s and everything seems perfectly stable - few of these disconnections were caused by me, pushing new versions to live server.

I'm being pretty optimistic and I'd like to encourage more users to move to Stratum protocol, or current Stratum beta testers to move more hashpower to it.

I knocked up short page describing main advantages of using mining proxy for miners. There're also step-by-step instructions how to run mining proxy on your rig: http://mining.bitcoin.cz/mining-proxy-howto

Stratum submitted around 300k shares. We need much more power to find the block in some reasonable time to confirm that everything is working correctly. Of course I tested it on hundreds testnet blocks, but I'd like to see first livenet block mined by Stratum pool soon :-).

Actually I don't want to became a miner developer, it's over my time capabilities. Maintaining a fork of miners with stratum protocol is quite overhead, accepting a simple patch by the mainline would be much easier, obviously.

"SocketTransportClientFactory connection timed out" - looks like firewall issue. Don't you have some ports blocked?

You still don't fully understand it. Actually pool send much less amount of data than with getwork. You should really read "real world example" from the Stratum documentation page. If you're miner developer, you'll be surely familiar with the howto.

The new protocol really don't change any transaction confirmation times. Nothing changes in this area. Protocol just optimize the overhead on every level and give the miner great oportunity to iterate not only over ntime and nonce, but also over extranonce. And with cost of only one double-sha256 hash per new coinbase. Isn't that great? :-)

It's the same like designing the universal car. We should have just one model which will fit small city car, family car, a van and the crane. We definitely can design one machine which will fit all these needs just by mounting some special equipment over it. But we just don't want to, because it will lead to overcomplicated monster with many exceptions in the *real* implementation.

Look around you at this time. Miner software cannot follow even such dumb protocol as current getwork is. I don't want to show you my pool source, because I'm shy for tons of hacks involved because of crappy miner support. This is real-world lesson and we should learn from it. Please don't repeat same design mistakes with the full featured protocol which is ten-times complicated than getwork.


Then please show me exact payload done by GBT and providing exactly the same behaviour like Stratum does in the documentation example. And please don't use submitting whole coinbase. It's impossible to do full validation of coinbase for every share.


Which features they *really* need from GBT except?


For the god sake, how you can manage miner implementation if every pool operator will have full freedom in implement any of BIP option?

Well, I don't want to start flamewar and personal fights, really. I did the Stratum just because of my requirements, not because I wanted to compete with anybody. Let me explain it:

Actually I see the difference between Stratum and GMP as Electrum client and Satoshi client. You can achieve similar results with both of them, but every of such solution has pros and cons.

Two days ago I summarized my reasons for Stratum here: http://mining.bitcoin.cz/stratum-mining

I was comparing it mostly with the getwork, because it's the only used protocol by real miners now (voting by the hashrate). Maybe I should write up longer comparsion between Stratum and GMP. Back to the topic.

THere's really no need to have one super-protocol which fits all needs. By the way, I'm using getblocktemplate in the Stratum implementation myself and I consider it as a great way how to relocate pool logic outside the bitcoind. GBT is surely very complete protocol and you can do anything what you want, *if* you know how. I see GBT as very complex and very hard to implement full specs without breaking anything. Luke will say the oposite, but GBT has simply unnecesary compexity for the environment of pooled mining. You know, many optional features etc. But pooled miners don't need that. Period.

In the oposite we proposed complete stack for pooled mining, which *is* very lightweight and straightforward to implement. Simply said, there's not a *single* optional feature, which is possibly the biggest benefit of whole concept. Miners don't want tons of options, they need simple and clear algorithm how to talk with the server. It includes also exact specification of used transports and mechanisms for real-time broadcasting new jobs to the client. Current BIPs don't care about this anyhow, because they don't need to. Both are just for different use cases.

Luke told me yesterday, that GBT is not bounded to HTTP, that it can be implement with any transport. By mistake he expressed the exact reason why it isn't suitable for pooled mining. It gives miners/pool ops degree of freedom which don't help anything, just mess the source code of miners and pools, because interpretation of the current protocol "as is" is ambiguous and cannot be used by some additonal specification about transports etc.

By the way, pool servers must be super-optimalized for handle high loads. Current Stratum protocol implementing coinbase templates is definitely the most optimized solution for given purpose and I doubt that any getblocktemplate pool would be more optimized that this.

mining_proxy.py --help will prints all options.

Specifically to your request, use "mining_proxy.py -gp 8330" (or any other port number). "gp" identifies "getwork port"

doubles, just telling anyone's support is valuable feedback at this time. Any vote counts, because there's still a long way to roll native support of this protocol into major miners. During this period we'll have painfull times while running both pools at the same time .

Fine, I just finished necessary maintenance on the stratum pool. Load balancing is now in use. Not that it's required for 30 connections, but it's better to tune it up early. Now I can add backends into the loadbancer without interrupting current connections (which is anyway great improvement over Nginx load balancing used on getwork pool).

Now I don't know about any issue with Stratum and I'll leave it running for some time, to collect some stats (and hopefully solve the first block!).

Great. I expected that it is related to the protocol proposal. I was surprised because actually it *is* event driven :-)

What do you mean exactly?

LOL, typo. It should be "There's basically NO reason why..." :-)