stratum, nonce2, p2pool, and hash collisions

[mdude77]

I'm trying to understand how a stratum proxy works, which I think sort of what the stratum part of p2pool is, as well as Slush's stratum proxy.  I'm hoping there's a flaw in my logic somewhere or I'm missing something.

Here's how I understand it. 

p2pool determines the coinbase needed for the block we're trying to solve.  that coinbase, among other things, contains the payout addresses of the users in the sharechain and the amount each user should receive should the block be solved.

according to the stratum docs I've read, the beauty of stratum is that the miner generates the work.  for that to happen, the stratum server feeds the miner everything it needs to generate work, including the coinbase, a nonce1, and the required size of nonce2.  the miner derives nonce2, which is how the miner is able to generate work.  I think in most cases nonce2 is nothing more than a counter, since changing the value by 1 is enough to generate a completely different hash, and maybe just maybe solve a block.  Regardless of whether it's a counter or not, the size is still controlled by the stratum server (p2pool in this case).

here's where I'm stuck.

if the nonce2 size is 4 bytes, there are 2^32 different possibilities, or to be precise, 4,294,967,296 possibilities.  that's roughly 4.3 billion.

so, p2pool gives the miner the work.  if it's a 4 byte nonce2 size, the miner has 4.2billion hashes it can go through before it starts generating the same hashes again, unless p2pool gives it new work.  unless I'm missing something, a miner running at 1 gh/s will take 4.2 seconds to go through all those possibilities.  an Ant running at 180gh/s will exhaust that in 0.02 seconds.

I have to assume my math is wrong, or nonce2 is much larger than 4 bytes.  otherwise my ants are wasting a lot of time.

that's just one worker.  let's say there are 10 workers on the pool.  p2pool has to be providing unique work to each miner, else each miner will eventually be generating the same hashes, unless nonce2 is sufficiently large, or each gets a different nonce1.  I have to think this is working properly, else when a valid block is out there for a certain hash, more than one worker is going to find it, it's just a matter of who gets it first.

now if I consider Slush's stratum proxy, I get more bewildered.  let's say you have this stratum proxy sitting between you and a stratum pool.  you do that so your 10 ants use one connection instead of 10 connections.  the pool feeds the proxy the required work, coinbase info, nonce1, and nonce2 size.  the proxy now needs to relay to that to the workers in a way that each will generate unique work, else they are working redundantly.  if nonce1 is unchangable, we have the same problems.  nonce2 has to be large enough so that each worker gets a large enough space so that it doesn't exhaust the entire space before new work is available and also doesn't cross over into another worker's work.

this leads me to believe:

1 - I'm missing something fundamental
2 - nonce1 can be changed without the pool objecting
3 - nonce2 is much much larger than 4 bytes

can someone help please?

thanks.


M

[1713995851]

1713995851

[1713995851]

1713995851

[1713995851]

1713995851

[roy7]

This is lower level than I understand, but maybe you can learn something helpful from:

https://github.com/dogestreet/proxypool

[mdude77]

This is lower level than I understand, but maybe you can learn something helpful from:

https://github.com/dogestreet/proxypool

Thanks.  This gives me a clue:

The idea is to reduce the size of extraNonce2 so that the server controls the first few bytes. This means that server will be able to generate a unique coinbase for each client, mutating the coinbase hash.

This reduces the block search space for clients. However, the impact is negligible. With a 4 byte upstream extraNonce2, and with the proxypool server keeping 2 bytes for itself (clients get the other 2). This allows the server to have 65536 concurrent connections and clients to have a maximum hashrate of 2^32 x 2^16, or 256 tera hashes per second, which is more than enough for Scrypt based coins at the time of writing.

What I don't understand is how that reduces to 2^32 * 2^16.

M

[maqifrnswa]

stratum adds nonce2 in the coinbase, but you also get to change ntime (and nonce) both in the header like you could with getwork
http://mining.bitcoin.cz/stratum-mining

edit: 2^32x2^16 corresponds to how many connections a proxy server can have open at a time: 4 bytes for the pool you connected to, two bytes to identify the proxy server connection . In one second, ntime doesn't change - so the maximum number of workunits your server can generate in a given second is 2^32x2^16=2.8147e+14 workunits/second. (one workunit=one hash)

with the above proxy server, your individual miner can create 2 bytes (extranonce2)+4 bytes (nonce) 2^8*2^32 work units per second = 1e+12 workunits/second

EDIT2: without stratum (i.e., only using getwork), both the proxy server and an individual miner is limited to 2^32=4.2950e+09 workunits/second

[mdude77]

stratum adds nonce2 in the coinbase, but you also get to change ntime (and nonce) both in the header like you could with getwork
http://mining.bitcoin.cz/stratum-mining

edit: 2^32x2^16 corresponds to how many connections a proxy server can have open at a time: 4 bytes for the pool you connected to, two bytes to identify the proxy server connection . In one second, ntime doesn't change - so the maximum number of workunits your server can generate in a given second is 2^32x2^16=2.8147e+14 workunits/second. (one workunit=one hash)

You individual miner can create 2 bytes (extranonce2)+8bytes (nonce) 2^8*2^64 work units per second = 4.7224e+21 workunits/second

EDIT2: without stratum, both the proxy server and an individual miner is limted to 2^64=1.8447e+19 workunits/second

aha!  It's the nonce I haven't discovered yet.  That isn't in the stratum protocol, which is why I missed it.

So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce.  That's plenty of space.

thank you.

M

[-ck]

aha!  It's the nonce I haven't discovered yet.  That isn't in the stratum protocol, which is why I missed it.

So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce.  That's plenty of space.

Normal 4 byte nonce.

[mdude77]

aha!  It's the nonce I haven't discovered yet.  That isn't in the stratum protocol, which is why I missed it.

So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce.  That's plenty of space.

Normal 4 byte nonce.

thank you.

I take it modern miners are aware if they reach the end of the space for the nonce and then increment something else, like ntime?  how soon do you think we'll run out of space?  a 1th/s miner would pound that space pretty quickly.

M

edited

[-ck]

aha!  It's the nonce I haven't discovered yet.  That isn't in the stratum protocol, which is why I missed it.

So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce.  That's plenty of space.

Normal 4 byte nonce.

thank you.

I take modern miners are aware if they reach the end of the space for the nonce and then increment something else, like ntime?

M

No need, as 8 bytes total is already a ridiculous amount of hashes.

[maqifrnswa]

aha!  It's the nonce I haven't discovered yet.  That isn't in the stratum protocol, which is why I missed it.

So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce.  That's plenty of space.

Normal 4 byte nonce.

yeah, I fixed that in my post too, thanks