[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[digital]

Hi guys,

I'm finishing project on which I recently spent some time  . I'm just writing official announcement and internal technical documentation. But in the meantime I would like to ask you for testing this:

https://github.com/slush0/stratum-mining-proxy (there's also prepared Windows binary)

It is proxy between "old" getwork protocol and new pool interface based on Stratum protocol (which I originally designed for a lightweight Electrum wallet). As I said, I'll post it's benefits officially later, but I'd like to do some small-scale testing for now (and hopefully find the first block outside testnet?). So if you have some spare time, please run mining proxy locally (using default parameters is fine) and point some of your miners to it (by default it listen on localhost:8332).

It is still experimental version, so don't be surprised if something will go wrong :-). Anyway, submitted shares should be accounted under your profile as normally...

P.S. As my "thank you" for your help you should see very, very low stale ratio.

P.P.S. Of course please report issues if any. Problems with installation, runtime errors, authorization errors, rejected shares, whatever...

hey Slush, I was wondering if you were still working on the DGM system?

Im sure its a huge project, but I was just curious if it was something that was still on the table.  We haven't heard anything about if for a bit so I figured I would ask...

[slush]

hey Slush, I was wondering if you were still working on the DGM system?

Im sure its a huge project, but I was just curious if it was something that was still on the table.  We haven't heard anything about if for a bit so I figured I would ask...

Hi digital, that damned DGM :-). Actually this project fits my plan to DGM very well; I implemented DGM on old pool core, but it was buggy and I was affraid of putting that on production. DGM, in contrary to current rewarding mechanism, needs central point of truth - DGM calculation does not depends on time like score method, but on total count of submitted shares, which is quite hard to obtain *exactly* in such distributed environment.

For that reason I'm finalizing whole new concept of the pool, which solves many major issues of original, two years old design (these days I was quite happy when pool crosses 10 GHash/s) and new framework give me not only the chance to scale the pool infinitely, but also the possibility to implement any thinkable concept of calculating block rewards.

So very soon after I get this new core stable (it looks quite nice so far, but I still need more hashpower to test it properly and find a new block) I'll change the pool rewarding system. I'm planning both DGM + PPS.

Digital, I know that DGM support is never-ending story, but now I'm really close :-). You can help me out with the testing of the new core anyway ;-).

[digital]

Sounds good, Ill definitely chip in with the testing...

[digital]

pretty easy setup on Windows 7...

Anyone else on Windows 7 will want to make sure the firewall allows the proxy access on your network type (domain, public, or private).

Edit-

For anyone who's using GUIMINER and wants to set this up, all you need to do is install the Windows version of the proxy from the links above.  
Then when you have the command window open, change your Server settings in GUIMiner from Slush's pool to "Other", then just type localhost into the host field.  
All the other settings should be good from the previous pool setting.  Then just save it and your good to go.

[slush]

pretty easy setup on Windows 7...

I forgot to explicitly mention the fact, that you can connect to one proxy as many miners as you want. So this is recommended solution  if you're running more rigs on one place. It will save you bandwidth and reduce stales a lot.

[digital]

pretty easy setup on Windows 7...

I forgot to explicitly mention the fact, that you can connect to one proxy as many miners as you want. So this is recommended solution  if you're running more rigs on one place. It will save you bandwidth and reduce stales a lot.

So does that mean if I have four computers in my bedroom, I can have the one running the proxy connect to localhost, and the other three connect to 192.168.1.x:8332?

[slush]

At this time, proxies cannot be "chained" together (although it is teoretically possible). However you can connect all miners to that one proxy running on one of your computer/rig. By default, proxy listen on all network interfaces, so if you allow it on firewall, it will be accessible from your home network without any further configuration.

Short summary:
1. Install the proxy
2. Run it on one machine
3. Obtain IP/hostname of this machine
4. Point all your rigs to this hostname on port 8332

I was considering if proxy should listen on all interfaces or only on internal network interface of the computer, but there's no risk involved. It is just getwork interface which cannot be misused by possible attackers in your network. In contrary theres the benefit of running one proxy for all rigs in your basement without any difficult setup...

So does that mean if I have four computers in my bedroom, I can have the one running the proxy connect to localhost, and the other three connect to 192.168.1.x:8332?

[dburdett84]

I have both of my workers running on it now, and it seems to be a little faster then just using gui miner to connect to the pool, I just pointed them at localhost:8332 like you suggested.

The only odd thing is that GUI miner is only showing 90khash/s on one worker, and 2.1Mhash on the other worker, but I know that it is churning out faster then it was before (280Mhash/s per worker) based on the number of shares.

[Tittiez]

I have both of my workers running on it now, and it seems to be a little faster then just using gui miner to connect to the pool, I just pointed them at localhost:8332 like you suggested.

The only odd thing is that GUI miner is only showing 90khash/s on one worker, and 2.1Mhash on the other worker, but I know that it is churning out faster then it was before (280Mhash/s per worker) based on the number of shares.

From what I understand, with GUIMiner you don't need to use the proxy, it is built into the miner. I might be wrong, slush must clarify.

[slush]

dburdett83 - That sounds quite strange. Are you sure that you don't have multiple miners working on the same machine? Proxy itself should not affect mining in this way.

[slush]

I have both of my workers running on it now, and it seems to be a little faster then just using gui miner to connect to the pool, I just pointed them at localhost:8332 like you suggested.

The only odd thing is that GUI miner is only showing 90khash/s on one worker, and 2.1Mhash on the other worker, but I know that it is churning out faster then it was before (280Mhash/s per worker) based on the number of shares.

From what I understand, with GUIMiner you don't need to use the proxy, it is built into the miner. I might be wrong, slush must clarify.

I'm working on native guiminer support, but it's not ready yet. Btw I'm just updating the document, "compatibility" section is not up to date yet .

[eleuthria]

I have both of my workers running on it now, and it seems to be a little faster then just using gui miner to connect to the pool, I just pointed them at localhost:8332 like you suggested.

The only odd thing is that GUI miner is only showing 90khash/s on one worker, and 2.1Mhash on the other worker, but I know that it is churning out faster then it was before (280Mhash/s per worker) based on the number of shares.

From what I understand, with GUIMiner you don't need to use the proxy, it is built into the miner. I might be wrong, slush must clarify.

I'm working on native guiminer support, but it's not ready yet. Btw I'm just updating the document, "compatibility" section is not up to date yet .

Please get something up soon slush!  Since the two proposals we have are almost identical, I'd be more than happy to remove my proposal unless there's something that seems very wrong.

If you don't have it as part of your spec yet, please consider the two server-related pieces from my proposal:  SERVERRESTART and REDIRECT.  So pools can warn miners of an impending restart (immediately move to failover pool rather than risk wasting work) and so pools can redirect miners straight from the protocol (allows pools to more easily load balance miners without the need for external servers/software).

[dburdett84]

dburdett83 - That sounds quite strange. Are you sure that you don't have multiple miners working on the same machine? Proxy itself should not affect mining in this way.

It's not actually slowing it down, just for some reason is causing guiminer to report it as slower, from monitoring the dashboard it is just as fast if not a little faster then without the proxy running.  Just wanted to let you guys know what I saw.

[ninjaboon]

i finally found my first block!!! and on my slowest machine to boot, go 70 Mh/s 

wow ! is that possible? lol. I'm gonna get a few 5770 GPUs now.

[slush]

I finally posted some docs. I wrote these examples off my head so maybe there're some mistakes, but in general it should be fine.

https://bitcointalk.org/index.php?topic=108533.0

eleuthria - it is quite funny how we solved some things in the same way and the rest in the completely different way :-). At this time I documented only mining core (e.g. how to build block header and submit the share), but I've implemented some maintenance methods in the current proxy as well and I'll put them to docs soon.

[eleuthria]

I finally posted some docs. I wrote these examples off my head so maybe there're some mistakes, but in general it should be fine.

https://bitcointalk.org/index.php?topic=108533.0

eleuthria - it is quite funny how we solved some things in the same way and the rest in the completely different way :-). At this time I documented only mining core (e.g. how to build block header and submit the share), but I've implemented some maintenance methods in the current proxy as well and I'll put them to docs soon.

Actually, we solved it the exact same way.  Our work payloads are identical, just in a different order.  Our submissions are identical, except for ntime rolling in yours vs static in mine (we figured 18 Exahash was enough to avoid having to do any kind of ntime modifications [saves the pool from having to verify ntime]). 

I really only see two differences:
1) You decided to encapsulate it with JSON whereas mine was using plaintext command verbs.
2) 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).


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.

Luckily, our designs are so similar that it shouldn't even take an hour to update my custom pool to use your implementation.

[slush]

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?

[eleuthria]

From my experience this "development stage" can take some time :-).

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.

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?

Well, my protocol has been final for a few months (only recent changes were the server redirect/shutdown messages).  Unfortunately, I didn't know nearly as much about bitcoind internal workings as you did, so implementing it in a pool took a lot more work.  But our designs are just so similar, there's no reason to fight over it.

Very nice! I expect your solution is proprietary? Which technology did you use? Java?

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 .

[slush]

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 :-).

[digital]

Since the end of the last block (duration 6:25:50)  I havent had any of my shares recorded in my account page.

I'm running my miners through the proxy.  It's only been a few minutes, hopefully there's just a delay, and I'm jumping the gun....

:Edit:

I just reconfigured one of my miners so it was running without the proxy, and the shares are showing up.  So it definitely looks to be something up with the proxy reporting shares...