Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 775. (Read 4382786 times)

That would mean be the pool reports the IP of the miner to the network and I cannot think of any reason for that. Besides, there's no exact way to tell the location of an IP.
But I may be wrong. Somebody, please enlighten us.

now i'm confused. When you look at the Statistics page and click on the block number, don't you see where the member of the pool is located?

ie: http://blockchain.info/block/000000000000009b2d787db18f0b7967e4944d0b6796835c1e6e2f51b3e99e76?site=slush

But blocks listed as relayed by a server in Germany means that's where the pool server or single miner is located, not where the miner pool member who found the block is located? Or am I wrong?

EDIT: I mean, if the miner in Germany is not a pool member it wouldn't affect our rewards.

hmmm... I was just looking at my results for the last 12 hours and decided to come and see if people were yelling about problems. And, as i suspected, they are. Yesterday, i was looking at blocks and the maps where they were found. I noticed a number of them were found in a certain section of germany. It kind of implied that the same person was finding a disproportionate number of blocks. I asked my self how this could be and decided that it is either a large mining complex, or an ASIC miner. I'm leaning towards ASIC at the moment. I'm not pointing fingers or making accusations, just observing and taking a WAG at it.

As ASIC are bursting on to the scene, we are going to see that we nonASIC users are getting smaller shares. or no shares of some blocks. This will continue until the difficulty adjusts for the speed of the ASICs. Once the difficulty is adjusted it will be obvious why we are getting little. But, in the mean time i suspect what we see will appear to resemble anomalies.

Me too.

Mine did the same, only it said three and a half hours. Thing is there were a couple of short blocks during that time period where I did have shares. So I was mining, it just wasn't showing up on the account page for some reason.

Same here...

Actually I think something a bit more is needed or a dishonest pool could still skim by handing out different merkle trees to different miners.  (Miner A would see his past contributions in the merkle tree path he receives, Miner B similarly, but A's contributions could be missing from B's tree path and vice-versa.  The dishonest pool could then plausibly deny the tree path as a fabrication.  Probably an ECDSA signature from the pool could fix that (from the reward private key, or separate "fairness" key pair).  Miners can audit the blocks, and in the unlikely event of a pool skimming can prove it, which could create reputation problems for the pool.  Or as before more directly publish the proof of skimming to be validated by the network with some outcome - eg block declared invalid, or pool fees reassigned to first skim prover (a kind of multisig).  I think a signature is not quite as desirable as the verification is higher than for hashes, but I dont so far see a network efficient way to avoid it.  Anyway the signature does not have to be published nor verified unless the pool cheats so that is probably acceptable.  If the punishment for cheating is that the block gets invalidated, there is no reward possible from any form of hacking of the pool server including obtaining its fairness private key.

It would be possible to have a fair exchange protocol as part of the mining share submission (as the signed proof of past work is delayed until after the work is submitted, a dishonest pool could accept a mining share work proof, and then not respond, claiming network error).  However fair exchange is a tricky somewhat computationally inefficient area of cryptography involving an arbitrator in event of dispute, and fair exchange doesnt seem that necessary - the pool doesnt want to lose miners, is probably deterrence enough.

Adam

Dont you keep the slush reward address private key offline, & airgapped?

Then payouts can be batch calculated from a USB key transfer of a share work tally db report, and usb key transfer of the payout transactions to the pool miner addresses say once per week or whatever.

Then the worst that the attacker can do is delete some of the share work tally db records, or change the reward addresses in the db to themselves.  And if you notice an attack, even the miners could resubmit the shares.

And in fact the pooled miner reward addresses should be included in an additional merkle tree in the coinbase itself, and the pooled miners should be presented a verifiable log2 path showing their presence and number of contributions within the coinbase, so that if they can see their contribution is missing, either due to pool skimming, or pool share work db compromise they can switch to another pool.  In this way reward can not be reassigned, without redoing the work, and other than the pre-mining attack, you could basically operate with zero-trust (give out the ssh root private key to the serer without loss of security.)

The proof of contribution merkle tree could even be published to the full network, and included as part of the reward verification, then the pool wouldnt need to be trusted at all in terms of provable no skimming.  Of course the pool is still trusted with validation (by those pool miners who dont build their own blocks nor independently validate the pool constructuced blocks).

Adam

Hi joolz,

just speculating, of course! To get a real handle on it we'd probably need to find the standard deviation of the distribution, then we could comment on how likely it is for any particular result to be  a particular percentage out, and indeed any particular *random* sample of results (rather than a selected group that catch our eye)...

Looking at my 7-day moving average from the stats page, however, it's followed quite closely my increase in hash rate and the difficulty change of 30.04, although the last couple of days aren't there yet, so I'm not concerned (at the moment...)

Doesn't preclude a temporary loss, of course. I did notice my cgminer report a missing connection briefly a few hours ago...

Shares are missing in my last blocks too. Is something wrong with stratum again?

Well if you saying a variance of over 30% is normal then im lost, maybe a few % not 30%

joolz

My flags are your typical -w 128 -v -f 30

EDIT: I also noticed that I can get ~620 Mhash/s only with 13.1 catalyst. Anything else and it is only ~560

Any higher core speed and card becomes unstable, however I suppose if I Overvolted it would be fine... Don't want to do that after reading horror stories on this forum thou

Yes but change is less then 10%... This can't be the reason... And c at my heshrate isn't issue.

17852 is off by 25% again... Are we having troubles?

The first 3 were a bit lower for me, the last two a bit higher. May just be normal variability with c=210 (as per those maths links posted a few pages ago... )

Also I see pool hash rate now over 9100G - so I'm expecting lower payouts but more frequent payouts compared to a day or so ago when we were on low 8- something Ghash... (same daily payout on average until next diff change, of course).

Sometimes my shares show up low but when I check 5-10 minutes later it goes up.  Not sure if thats what your noticing.  If not it could have been some kind of connection issue near the end of the block.  Even a few shares dropped will mess with the numbers.

lower payouts on 17826, 17827, 17829, 17844 and 17845.

The last 2 are about 30% lower than my normal?

joolz

I just noticed one of the workers happily submitting shares while the account page says I submitted nothing for over an hour. I reconnected and normal operation resumed.

I wonder if a hacker figured out how to redirect mining streams.

Notice that I'm missing about 10 to 20% of the reword for blocks 17846 and 17845, 17842 and 17841, 17837 and 17836. Unlucky or a problem? Some are over hour so luck shouldn't be a problem...