Bitcoin Forum
November 21, 2017, 09:04:35 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: [ANN] Stratum mining protocol - ASIC ready  (Read 143503 times)
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 03:07:01 AM
 #1

Hello all,

I'd like to announce my proposal for new pooled mining protocol.

All details and links can be found here: http://mining.bitcoin.cz/stratum-mining

I'm running experimental pool since yesterday. You can connect to it using mining proxy, which is linked from the document above.

Both pool source and mining proxy is opensource!

I'm waiting to your comments :-)

1511255075
Hero Member
*
Offline Offline

Posts: 1511255075

View Profile Personal Message (Offline)

Ignore
1511255075
Reply with quote  #2

1511255075
Report to moderator
1511255075
Hero Member
*
Offline Offline

Posts: 1511255075

View Profile Personal Message (Offline)

Ignore
1511255075
Reply with quote  #2

1511255075
Report to moderator
1511255075
Hero Member
*
Offline Offline

Posts: 1511255075

View Profile Personal Message (Offline)

Ignore
1511255075
Reply with quote  #2

1511255075
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511255075
Hero Member
*
Offline Offline

Posts: 1511255075

View Profile Personal Message (Offline)

Ignore
1511255075
Reply with quote  #2

1511255075
Report to moderator
1511255075
Hero Member
*
Offline Offline

Posts: 1511255075

View Profile Personal Message (Offline)

Ignore
1511255075
Reply with quote  #2

1511255075
Report to moderator
eleuthria
Legendary
*
Offline Offline

Activity: 1750



View Profile
September 11, 2012, 03:36:34 AM
 #2

Well, I knew we were both working on something, and our limited conversation a few months back made me think we were attacking it in two very different ways, with my proposal being significantly better.  Now that you've released yours, I see they're almost identical.

I am withdrawing the protocol I've proposed and amending previous posts shortly.  Since our designs were so similar, I'll be updating my custom pool code to utilize the syntax you've defined.  We don't need a VHS vs Betamax competition for protocols which accomplish the same thing in almost the same way.  All pools and miners benefit from this new protocol, and the faster more pools show support to adopt it the better.

Please just adopt the two commands I posted about previously:  A redirect command for a poolserver to send miners elsewhere, and a server restart notification [with timer] so a pool can attempt a graceful restart rather than suddenly dropping connections.

Aside from that, lets get this stuff natively supported by mining software!

RIP BTC Guild, April 2011 - June 2015
Graet
VIP
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
September 11, 2012, 03:46:53 AM
 #3

Thanks guys, looking closely Smiley
Graet

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 03:48:09 AM
 #4

We don't need a VHS vs Betamax competition

+1

Quote
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.

Quote
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?

eleuthria
Legendary
*
Offline Offline

Activity: 1750



View Profile
September 11, 2012, 03:52:03 AM
 #5

Quote
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?


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.

RIP BTC Guild, April 2011 - June 2015
Graet
VIP
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
September 11, 2012, 03:55:32 AM
 #6

Quote
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?


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.
This is  a very nice idea Smiley

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 03:58:39 AM
 #7

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.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
September 11, 2012, 05:15:56 AM
 #8

Not sure this is really any different/better than the BIP 22/23 standards which have been in open development for months...
as for the comments on it in the Stratum mining protocol doc:
  • the fundamental BIP 22 operation is fairly easy to implement, just making use of the more advanced functionality (which StratumMP doesn't even support yet) is more complex
  • GBT does not require or depend on HTTP; it is intentionally designed to be JSON-RPC over any transport
  • GBT does not require a complete dump of the server's memory pool
  • checking shares shouldn't be any different AFAIK?

We don't need a VHS vs Betamax...
Perhaps it would have been a good idea for you and slush to participate in forming the standards instead of privately working on duplicate protocols? :/

slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 05:54:58 AM
 #9

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.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
September 11, 2012, 06:05:03 AM
 #10

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.
BIP 22/23 is only complex if you make use of the extensions that don't exist for StratumMP at all. If you don't, it's in fact just as simple (perhaps simpler).

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.
Block building is the same no matter what protocol conveys the data... if you're not happy with the current level of documentation, it makes more sense to improve it rather than just start from scratch.

For this reason I picked the best things lying around and knocked up this proposal & implementation, which can be used here and now.
gmp-proxy has been functional on open source Eloipool-based pools for months.

Garr255
Legendary
*
Offline Offline

Activity: 952


What's a GPU?


View Profile
September 11, 2012, 06:09:25 AM
 #11

Thanks slush!

“First they ignore you, then they laugh at you, then they fight you, then you win.”  -- Mahatma Gandhi

Average time between signing on to bitcointalk: Two weeks. Please don't expect responses any faster than that!
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 06:15:17 AM
 #12

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-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
September 11, 2012, 06:23:31 AM
 #13

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.
Sure, gmp-proxy isn't exactly written to be readable - it's just a quick proxy cobbled together. Doesn't change the fact that it works. Wink

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.
You have to keep 10k connections no matter what protocol you use over them, unless you're using UDP (which is a bad idea for other reasons). Long polling itself moves load to be server-driven, though that of course won't help the problem of announcing new blocks all at once no matter how you do it. A pool that doesn't want users to request new templates on their own could simply set the expiration on it to 90 minutes later and only return new ones via long poll responses. Besides, CPU mining is dead and will only get more dead as ASICs go online. There's no reason they can't continue to use getwork until they're gone completely.

slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 06:26:45 AM
 #14

You're right.

VeeMiner
Hero Member
*****
Offline Offline

Activity: 751


bitcoin hodler


View Profile
September 11, 2012, 10:12:36 AM
 #15

great stuff for the bitcoin community, thank you!
wknight
Legendary
*
Offline Offline

Activity: 888


Bitcoin calls me an Orphan


View Profile WWW
September 11, 2012, 03:28:47 PM
 #16

This is excellent. Very nice work!

Mining Both Bitcoin and Litecoin.
eleuthria
Legendary
*
Offline Offline

Activity: 1750



View Profile
September 11, 2012, 08:25:18 PM
 #17

Giving this a little boost:  This is way too important to let it slip from the top topics.

I have almost finished reworking my custom pool to use the stratum protocol over my proposal.  By this weekend there will be at least one more publicly available pool supporting it (1 week trial period at 100% PPS rates).

RIP BTC Guild, April 2011 - June 2015
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 10:16:00 PM
 #18

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

doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
September 11, 2012, 11:33:08 PM
 #19

Giving this a little boost:  This is way too important to let it slip from the top topics.
It'll take a while for those of us who've only just seen it to implement it. I'm interested in adding support for it to my pool but it'll take time to write and test.
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
September 11, 2012, 11:39:28 PM
 #20

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 Smiley.

Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!