Topic: Attention ALL Stratum pool Admins! (Read 5035 times)

Could something like this combined with say a pool with 50% + of the network hashrate (at times up to 75%) cause a blockchain to stall, say for 1 1/2 hours at times with no found block?

At my last straw here LOL

This person has been banned. He only made ~30k MYR before I banned him.

Pool owners should ban this kind of hashrate. If it was real, he could be solomining.

On stablehash Groestl, someone take 99% of all rewards, sending thousands shares while other send 5 or 6.. Look at the invalide rate too..



I don't think this guy find any block too, but in anonymous, we can't verify..

There is some exploit out there..

Hello everyone,

I'm trying to understand this stratum exploit better, and something is confusing me.

The lowest difficulty is defined by the biggest target. So if we look at the nBits of the genesis block, we then convert to hex (from the compact representation) to get the diff 1 targets.

In BTC, genesis.nBits    = 0x1d00ffff;

https://en.bitcoin.it/wiki/Difficulty suggests we convert to a hex representation like:

so the hex target is
0x00ffff * 2**(8*(0x1d - 3))
or
0000 0000 ffff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Which matches https://github.com/Crypto-Expert/stratum-mining/blob/master/lib/template_registry.py where for sha256

diff1 = 0x00000000ffff0000000000000000000000000000000000000000000000000000

Now looking at a scrypt coin, eg LTC:

0x1e0ffff0 is the genesis block nbits

so the hex target is

0x0ffff0 * 2**(8*(0x1e - 3))
or
0000 0fff f000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Which doesn't match stratum-mining

 if settings.COINDAEMON_ALGO == 'scrypt' or 'scrypt-jane':
            diff1 = 0x0000ffff00000000000000000000000000000000000000000000000000000000

ie. the stratum-mining code has 4 leading zeros in the 64 byte hex representation of the target, wheras I get 5 leading zeros when doing the conversion from the compact to the full hex representation of the max difficulty.

I'm sure stratum-mining must be correct  - where am I going wrong?

this is absolutely right

they are and the stratum and sha algorithm's do. these idiot's using stratum without checking the diff1 are at fault and its their responability. it 100% isnt a fault in my code at all. i take responsability for scrypt and sha any other algo is up the user as i dont know myself how to calc what a diff1 value should be

hu?
arent pools supposed to check that the supplied share does meet thier diff requirements?

Heres how it works

Miner connects to pool, authorises and subscribes for work

Miner conencts sets their own diff and starts doing work. work is calculated by a DIFF1. (what the difficulty of a difficulty 1 share should be). Now if a miner hashes away at their hardcoded diff and ignores the diff the pool is sending. so the pool would increase their difficulty on the pools end to the max set (depends on the pool) and the pool wouldnt know that the miner is ignoring it. since the diff1 is wrong on the pool the pool would accept the difficulty the miner says it is and wouldnt check what the actual difficulty is.

This means stratum thinks the diff == (theoretic scenario of 2048) while the miner is submitting a diff of (theoretic scenario of 0.001) so the miner will get paid for hundreds of shares with a diff of 2048 when really it should be 0.001

For example:

If Coin hashrate: 200 , compile mining proxy with difficult ~150, and you will see accepted shares.

But this doesn't really clarify how this exploit pays out. If he doesn't actually contribute to the pool but still gets credited for crazy amount of fake shares then where does the pool get the reward for those shares from?

Okay back.

Done a test on stratum-mining and eloipool using the exploit documented above.
Stratum-mining and eloipool in scrypt mode both reject these shares.
This makes it almost 99% sure that it is a diff1 error and stratum-mining IS NOT at fault. the pool operator's are at fault for not using the correct diff1's for the algorithm

hmmm. thats what i would expect. tbqh darkcoin i couldnt give a crap about. its an unsupported scenario as i dont officially have it in the CryptoExpert repo. so any flaws are up to the OP. so atm i only care about:

Scrypt/ScryptJane (Uses Pooler's diff1)
Sha256 (Slush's Diff1)
Quark (PR from someone)
Skein (Uses SHA256 Diff1)

if we are talking about darkcoin - it should be the same as sha256

diff1 = 0x00000000ffff0000000000000000000000000000000000000000000000000000

problem is what should the value be  

i think this is a matter of changing diff1 in template_registry file

the big problem her is how to work it out. the only person i know who could do it is pooler.

this is my understanding also that pool ops have wrong diff1...

my personal belief. it affects other algorithm's where we do not have an accurate diff1

Need to test this. Maybe some pool owners can be fixed this.