|
Today I publicly asked developers of cgminer and phoenix if they're willing to support Stratum protocol. I already have confirmation from poclbm and Guiminer that they'll support it (m0mchil will implement it proactively for poclbm and Kiv will accept my patch which bundles proxy into the GUIminer).
|
|
|
|
the payout itself was what in the range it should have been, the estimated a tad low, but that always is for me. I do have to say with the proxy I am getting a faster rate, almost no stale's and a higher earn do to the speed increase.
These stale are related to server restarts which happen today because of rewarding system fixes. And now I'm implementing load balancing between more stratum backends. But from my previous tests in real environment, I had less than one rejected share per 10000 accepted shares using cgminer and the proxy, giving me 0.01% of stales, which is quite good  . |
|
|
|
Is that part of a new scoring system, or is that just because there's only 33 people using the proxy?
Matematically the scoring system is the same, there were only database issues which calculated score for proxy users out of the sync. But it should be in normal now. About those quick rounds - there's basically reason why the reward should be calculated in different way than before. |
|
|
|
Hello ckolivas, any chance to add native support for Stratum mining protocol? http://mining.bitcoin.cz/stratum-miningThere'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! |
|
|
|
Hello, any chance to add support for Stratum mining protocol? http://mining.bitcoin.cz/stratum-miningTwo pool are already supporting it (me and BtcGuild) and maybe other will join us, because that improvement against "getwork" is significant. Pools supporting Stratum have X-Stratum header in getwork response, so it is easy to switch to Stratum protocol transparently, without changing credentials/host/port by the user. There are three ways how to integrate this stuff: a) Startup stratum proxy as a separate process which will listen on some localhost port for getwork requests. Current Stratum proxy can handle this pretty easily. b) Reimplement stratum protocol into the miner. It isn't too much difficult if you've already some experience with handling block headers and hashing. c) This is the most likely solution for Python miners and especially these running on Twisted. I can add the feature to the proxy, that it will be able to run as a library. Potential interface would be extremely easy and if you already knows Phoenix internals, integration should be a matter of few minutes. Pseudo code looks like this: import mining_proxy
def on_new_template_callback(p, is_new_block):
print "New template is ready"
if is_new_block:
print "New block on network detected, we have to drop current work"
p.getwork()
# This will peform getwork call and detects X-Stratum header in the response
if mining_proxy.detect_stratum(host, port):
p = mining_proxy.MiningProxy(host, port, on_new_template_callback)
....
p.getwork()
....
p.submit(blockheader)
else:
# ....
What do you think about this? I'm not familiar with the Phoenix, but if I'll provide native Twisted library with such API, are you going to integrate it? The major improvement in all this stuff is that proxy is producing block headers locally, so getwork() responses are *really* *really* fast. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs. |
|
|
|
Can you specify it a bit more? What mean "overflows" in Ztex? How often it happen? I don't have a ztex to debug, but proxy is producing standard getwork payload and unless the data from the proxy are garbled, miner should not even notice that it isn't connected directly to the pool. Anyway thank you all for reporting bugs, it helps me a lot. I have noticed all seems fine with my cgminer mining but I do notice i keep getting overflows on ZTEX BTCMiner. This only seems to be occuring since I started running mining proxy.
Any thoughts?
EDIT: Just been watching all seems better for about the past 10 mins will keep an eye on it over night and see how it holds.
|
|
|
|
|
Is the block reward from last round in expected interval? I've fixed more small database-related bugs recently, which had an impact on block rewards of proxy users. Now it looks fine on all my testing accounts.
However the estimated reward looks a slightly lower than expected for proxy users. It's because new pool uses less aggressive method for storing shares into the database, so website calculates will obsolete data. It is quite expected and will disappear once more people will mine over Stratum (which will happen once there'll be native support at least in guiminer/poclbm).
|
|
|
|
|
Quick update: I'm working on the fix of reward calculations over the proxy. It should be running normally in few minutes.
|
|
|
|
From what I could tell, all the shares were actually counted. It just took 4 or 5 minutes before the shares that were found using the proxy actually showed up in my account...
Thank you, it helped me and I fixed yet another small bug. It should not appear now (and sorry for two quick stratum server restarts related to bugfix). |
|
|
|
Did you see these shares as accepted in proxy/miner? I'm thinking if it was just a connection bug or if it was related to the server somehow. Since the end of the last block (duration 6:25:50) I havent had any of my shares recorded in my account page.
|
|
|
|
How long did you run it without a restart? The Feb19 version is fixing such an issue which you descibes  |
|
|
|
Slush confirmed this IP is associated with his pool. the reason of this was hidden, now it's more clear.
I don't have any reason to hide my blocks. I even put '/slush/' into the coinbase . |
|
|
|
gmp-proxy has been functional on open source Eloipool-based pools for months.
To be honest, I don't understand how gmp-proxy works, so I'm unable to find out what the payload itself is. Cryptic variable names and not-a-single comment in the source code don't help the readability much. However you're still talking about payload, but it is just small fragment of the problem. I'm not sure how many connected users your pool has, but maybe keeping 10k+ connections from weird cpu miners will change your opinion. With the Stratum protocol, load is completely driven by the server, so I can handle these 10k connections with a single CPU core. |
|
|
|
|
Luke, nobody is saying that your baby is bad. I just think that BIP22/23 is too complex in parts which are irrelevant for pooled mining and it don't solve issues which are relevant there. So we're just solving another problem. Of course there's no reason to implement Stratum directly to bitcoind, as an example.
Actually I spent 90% of time on decisions not related to payload. As you wrote "it is intentionally designed to be JSON-RPC over any transport". Stratum protocol itself is the same, as you can read on google document specification. But to have viable solution for real-world miners, you have to propose complete stack and step-by-step algorithm, which obvously BIP22/23 isn't at this time.
For this reason I picked the best things lying around and knocked up this proposal & implementation, which can be used here and now.
|
|
|
|
|
It's just mailserver with running bitcoind and helping the block propagation. I don't see any magic involved.
|
|
|
|
The thinking is for when a pool is doing some kind of maintenance (either to update their code/settings, or reboot the machine). It's "good manners" for the pool to notify the miner in ADVANCE, that way they can move to a fallback pool/server before suddenly losing connection. A "retry/wait" time should also be included in the restart method, so the miner knows how long it should wait before trying to reconnect.
Ok, I can add it into the specs, but most likely I won't implement it in my code, just because all these fancy features are making things complicated, without providing any materialized benefit. For example the twisted framework in proxy is solving reconnections automatically for me, in exponential back-off (it will reconnect and if it fail, next retry will be after longer time). I think it's quite fine behaviour and forcing it to strictly follow the wait interval provided by the server will just require some hacks. |
|
|
|
I think it will be adopted faster than you think in this case. This isn't a bitcoind proposal which is a bureaucratic nightmare. It's a positive thing for everybody involved, and I doubt anybody could argue otherwise.
For everybody except the miner developers :-). Well, my protocol has been final for a few months (only recent changes were the server redirect/shutdown messages).
I did it quite in the reversed order. I firstly implemented the server (just as an freetime project) and then found that it can be useful for mining as well :-). So then I started to summarize all of my ideas from long talks with m0mchil and define the mining protocol itself. Unfortunately, I didn't know nearly as much about bitcoind internal workings as you did
me neither, hacking of bitcoind was a nightmare for me. But getblocktemplate is pretty straightforward concept. And I reused ArtForz's python code for serializing/deserializing all the low level stuff, so credit goes to him. I've been designing it in C++. I'm very...self conscious about my code, so it's really hard for me to make my pool software open source. Nothing to hide, other than the shame . Same here for my old pool sources :-). |
|
|
|
We don't need a VHS vs Betamax competition
+1 Please just adopt the two commands I posted about previously: A redirect command for a poolserver to send miners elsewhere
In the proxy source you can see methods client.reconnect(host) and client.add_peers(list). First one may be used for redirecting miners elsewhere, peer list is more for backup locations, when server crashes unexpectedly. server restart notification [with timer] so a pool can attempt a graceful restart rather than suddenly dropping connections.
What's the use case for this? If I want to restart the server I can do it without such command as it doesn't require any action from the miner side. Maybe I can add "wait" option to existing client.reconnect() instead? |
|
|
|
You allow multiple workers through a single TCP connection. It's mostly a design preference, not a major change (it would really only happen in the development stages when people are running proxies instead of miners that support the protocol natively).
From my experience this "development stage" can take some time :-). I'll be amending my proposal, I don't see a reason to try to start a protocol competition. Both of our solutions fix the problem, yours only has a few bytes of extra overhead due to JSON encoding, which really doesn't make a difference since you could still run a farm the size of the entire Bitcoin network on a 56k modem using the new protocols. If I had my proxy bridge for old miners to start testing I probably would've fought you on it, but since you also provided an open source poold, yours is easier for people to get off the ground.
That's reasonable and gentleman. When I read your announcement I worry about that a bit. What a chance that we both finalize the same project at the same time? Luckily, our designs are so similar that it shouldn't even take an hour to update my custom pool to use your implementation.
Very nice! I expect your solution is proprietary? Which technology did you use? Java? |
|
|
|
|
Show Posts
