Topic: "How to hop" has moved (Read 16281 times)

If you see anything wrong in any of the reposts, you can leave a comment by clicking on the little speech bubble at the bottom of the page. Or you can message me here.

Good luck,

where do I post edits?   

Since hoppersden.info is closing :verysadface:  I've moved 'How to hop' to:

http://howtohop.blogspot.com.au/2012/03/introduction.html

I wish 'myself' the best of luck in his future endeavours.

goodideaillhavetopaymoreattentiontoformattingorreaderswillfindittoohardtofollow .

Aha.

Ways To Present Information:

• Nested Lists
  • Organized
  • Easy To Read
• Unformatted
  • Complete Jumble
  • Information Unparsable

That would be 2 type ii, totally ignoring reality and making up your own game.


You think so, wouldn't you? So far I see a distinct lack of care. I wonder if some less scrupulous pools may head down that path since it's easy?

Yes, that blocks were a complete fabrication from a random number generator, and they were proxying and hopping with miner's hashes. Note that there are no real Bitcoin blocks linked or mentioned on their stats page. Making their fake blocks unprofitable to hop would be first priority in such a scheme, hence why the minimum solve time is >1/2 difficulty. Plus they can fake "unlucky" which they couldn't do if they were PPS.

The pool better publish their entire list of found Bitcoin block numbers and real finding times and submitted shares...or get tarred and feathered.

The graph shows three distinct stages, blocks <100 are more spread out, with just the expected short rounds missing (stolen?). Then after that, nothing that looks like pool rounds.

This is a really important point that I didn't follow until you mentioned that E[X/f(X)] = 1 for a system like this to pay the same as the original. All the time I worked on this I assumed:
1. The number of shares submitted to Bitclockers would be respected.
2. The block boundaries did not have to be respected.

But  as you point out, just having a loglogistic distribution of round lengths doesn't guarantee that there has been a mapping block boundaries onto loglogistic round lengths. So I've listed the implementations below.

1. Block boundaries respected: each share X is mapped to f(X), which can be a number larger or smaller than X.  I also measured the expectation E[X/f(X)] using mean(X/qllogis(X,4,scale=0.95))= 0.7606445, so I'm getting a similar result to you: 24% of the expected share value is unavailable using the transform.

Advantages: pool pays out only part of bitcoin reward. May be hopping resistant.
Disadvantages: May be noticeable since changing the number of shares retrospectively means altering all pool stats, which might be noticeable.

2. Block boundaries ignored: each share maintains 1:1 value (what I'd assumed was happening)
Type i: The number of shares in a the transformed round is generated using the number of shares in the original round. In this case payouts are equivalent to a process that generated blocks from submitted shares in a loglogistic distribution. Expected share value = 1.
Type ii: The number of shares in a round is generated entirely randomly in a loglogistic distribution. I like this option best. It takes less calculation, and if you're going to ignore block boundaries, then you can make up any kind of payout system you want without using any of the information from the original rounds.

Advantages: Don't have to worry about changing pool stats except for the round length. Definitely hopping resistant.
Disadvantages: Have to obfuscate block solve times which means not claiming any blocks at all.

Which gives me a great idea for a pool - a randomly generated payout method each round. You only get told which at the end of the round! :tongueincheek:

So were there other ways you thought a loglogistic distribution could be obtained that I should include in the list?

no.

huh, it really reminds me why my overall full day mining without hopping always comes short when compared to bclc. Checked my stats when my hopper machine was offline, they're normally off by .2 - .7 btc per day. some of it probably variance...but .7 btc?

All of the miners have been underpaid for short rounds. I'm not sure if fulltime miners have come out ahead or behind because what stats are available are either obfuscated or simply made up.

I'm assuming their methodology is as follows (and the fact they misreport block finding times suggests this may not be their methodology):
1. When a block is found, determine X, the number of shares since the last block (in multiples of the difficulty).
2. Report there were f(X)*D shares in the last round, and pay (50 BTC / (D*f(X))) per each share since the last block, for a total of (50BTC * X / (D*f(X))).
3. f is chosen so that f(X) will follow a specific distribution with CDF F2(X).

X follows the exponential distribution so the real CDF is F1(X) = 1 - exp(-X). To have a CDF F2 for the reported lengths, the transformation they need is f(X) = F2^{-1}(F1(X)).

If they take F2(X)=F1(X), then f(X) = X and they are not doing any transformation. This results in normal proportional payments.

If they make it so f(X) is always 1 (corresponding to number of shares per round precisely equal to the difficulty) - that is, the target distribution has no variance, it's a "random" variable that always takes the same value - they will always pay (50 BTC / D) per share, that is, they are handing out PPS payments which has high variance for them, and no variance for miners.

If they make the target distribution something in between, with variance less than exponential but more than a singleton, they will have some variance, but less than PPS (and for miners, less than exponential). But this is moot unless they choose the distribution so that E[X/f(X)] = 1 (the expectation is over the real exponential distribution of X) so that they pay 50 BTC per block on average.

There are several ways to go about it but they all require a good numerical root-finding/optimization function (which should take less than 10 iterations to converge). I copped out by simply fitting your reported mean and variance exactly. Expressing alpha in terms of beta is easy from one equation, and then you solve the second equation numerically for beta. A more accurate result can be obtained by taking some statistics (such as moments or quantiles) and building a loss function for any given alpha/beta combination based on their difference from the real values of the distribution, with a weight that depends on each statistic's estimate variance. Then it's just a matter of numerically minimizing the loss function over alpha and beta.

The best method would be Bayesian inference, but if we don't want to commit to any particular prior, the Maximum Likelihood Estimator is the next best thing. For any given alpha and beta, calculate the logarithm of the pdf at each datapoint, and add. Maximize this function with respect to alpha and beta, again with whatever numerical optimization function you have available.

PS if you can give me the complete list of values of round length divided by difficulty, I can try to run an MLE.

If it involves pointing fingers, it's politics in the wide sense of the word, it being a noble pursuit notwithstanding.

So you think they are reporting the correct block finder but not when the block is found? More evidence of block boundary tampering then. I'm sure someone who has more skills with blockchains.info than i do could track every bitclockers block down, backtrack and estimate how many shares were in each block.

I really am surprised no one has made these sorts of accusations against them before.

We don't know for sure that they're ignoring round boundaries because they don't own up to any block - so this is well worth my time looking into and an interesting idea. I hadn't thought to look for really nefarious activity.

Edit:What method did you use to calculate Beta? I ended up going with a brute force algorithm which was quick to write but not to run. Is there a better way - some regression technique maybe?

Politics or consumer advocacy? I haven't mined since October so I don't have a vested interest anymore. But dishonesty is bad for bitcoin - even if it was originally done with good intentions.

And about honesty - I wonder if even the Bitclockers.com pool ops realise that because they claim to have a proportional payment system: but actually don't, by their own definition they're underpaying miners if rounds are short.

How to hop 12 is finally done. I thought I had only one more post to go but after reading some of these posts, I doubt there'll be only one more. I think all pools need a thorough going over.


Can you expand on this a little?

What? You come into my house on the day my daughter is to be married and ...oh wait.

Pool hopping proportional pools is simple. It's when there are known or unknown anti-hopping protections that you'll earned less than the expected value of a share.

Even then, at least with all of the hop resistant rather than hop proof scoring systems, as long as you're there at the start you'll earn more than PPS payout. I haven't come across a proportional modification that prevented that entirely.

The difficulty in pool hopping is optimising. This means finding the correct %D to leave the pool for a particular payout method, making sure your software doesn't cause too many stales or miss round starts, having a system that allows the software to compare the expected value of a share at a particular pool at a particular %D, and probably lots more.

As far as manipulating hoppers to increase hashrate, I'd guess that is why they've used their score method the way they have - without actually owning up. That way they keep their hopper boost but lose less coinage from fulltime miners to the pool hoppers.

Really, it's quite a nice idea - a score system that doesn't need to keep track of anything other than users shares. But Slush's score system still does better because the expected value of a share at the end of a long round is still near 1.0. whereas at Bitclockers.com the expected value of a share drops more rapidly even than a proportional pool. And of course, any of the DGM solutions (I include PPLNS in that) beats the Bitclockers.com system hands down since they're not only provably hopper proof, they're can also be modified - to reduce miners variance for example. And you don't have to lie about your stats.

I made a very conservative estimate of how much they've underpaid pool hoppers over the last 200 rounds, and that's about 2000btc.

EDIT: The following may not be true because I didn't include in this analysis the fact they're messing with the round boundaries. If the modified round lengths are caused strictly by moving the boundaries, it's possible they don't have a hidden fee.

The situation may be much worse than we (I?) thought.

The average of their reported round lengths seems close enough to D. But this doesn't mean they pay fairly on average, since their payout per round is inversely, rather than directly, proportional to the reported round length.

So if f is their transformation function, the average total they pay per round is

$int_0^{\infty}\frac{e^{-x}x}{f(x)}\ dx$

I fitted a loglogistic distribution with alpha = 0.953236, beta = 4.55639 (I'm lazy, a better fit is possible), and the result turned out as 78%. That's right, they're paying 78% of the rewards, keeping 22% fee to themselves.

So I'd say their transformation has nothing to do with combating hopping, and everything to do with being thieves. I guess they thought they could get away with it by keeping round length average similar to the expected one. Seeing how long this went on, I guess they were right.

My calculations were kind of hasty and I'm not that much interested in these politics, so I'll let organ volunteer to make the "BITCLOCKERS ARE STEALING 20% OF MINERS' REWARDS" public announcement once he confirms this with his data.

Well investigated organ.  This isn't going to go down well I expect!

Yes, paying a 12*D round out as a 3*D round seems risky to me too. And yet with all the other options which can reduce risk for them and reduce variance for their miners, they decided to fake their most important stats for what seem to me to be venal reasons. I could (maybe) understand it if they did it for a couple of weeks during a change over to hopper proof method, but still going now?

I meant to add that they're also doing something funky with their block announcements - so I don't know if they are reporting their true hashrate but not their blocks, or if they are fudging the hashrate and keeping 'block timing' boundaries.

If you aren't going to respect block boundaries, why not DGM? Or PPLNS if you're old school and don't like flexibility?

How do you know this? That the reported lengths follows a log-logistic distribution doesn't mean they're just doing a simple transformation.

But if it is indeed a simple transformation on the round length, this means they are greatly increasing their own risk. (And it only has limited anti-hopping effectiveness.)

If they did a transformation based on a singleton target distribution, it would be PPS. What they are doing is something in between.

How to hop 11 with more on how Bitclockers.com have been paying some miners more at the expense of others.

I think a) covers that. I'm pretty sure that's all of the payout weirdness with them, unless you know of something else?