Vladimir's essential self-defence guide for Bitcoin Miners

[AnnihilaT]

Instead we can look at how close each pool comes to the expected block solves for a perfect pool with zero hardware, software, and network failures. Then we can have a degree of confidence about expected performance in practice.

Wasnt that the whole point of this exercise anyway (and the original post for that matter?) 

And if not, why not? 

What do I,  as a miner,  care about your hardware, software, or network failures?  I want a return on my electricity costs + margin and the rest is your problem and why i pay you a fee/donation.  I dont care about normalized statistical calculations about the probability of x and y happening if the end result is the pool  solving less blocks than expected or hoppers stealing a share of my earnings.

Judging from the growth we have seen at Mainframe,  im guessing we arent the only ones with this viewpoint.

I think we need to remember that whether or not Vladimir's math and methods are 100% agreeable to everyone,  the basic point of what he was trying to say is valid and sound, good advice for miners.  Beware pools which appear to under earn and pools which allow hopping (unless you plan to hop yourself).   Not because they are evil or cheating or anything else (while its possible they could be) but because it eats into your earnings.  This is just common sense and good advice and all the math in the world cant replace it.

[1714005193]

1714005193

[1714005193]

1714005193

[minero1]

There is a lot of stuff i don't understand in this thread, in Vlad's defence i might say that he kinda makes it a little bit easier for me to digest and this thread made me stop trusting blindly in pool ops.

what do you guys have to say about rfcpool, it's not in the list. thanks

[organofcorti]

I could run a exact confidence level model on several months of block finding, but I'm not enough of a math genius that I can immediately see how to also model the changing probability (difficulty) for the N trials in three months in code. It would probably involve making a data frame of all the block solves and running the vectors of shares and round difficulties through the poisson test though.

You could also run a quick simulation (see https://bitcointalk.org/index.php?topic=38785.msg486238#msg486238) and do a visual comparison on real data, which yes, you'd need to renormalise for each difficulty period. The advantage of using shares per round as a measure of luck is that renormalising the data is quite simple (list of difficulties and change dates here)

Note that this wont prove anything, but if you can model your simulation data accurately enough you'll be able to measure how far the real world data varies from it.

[k9quaint]

Instead we can look at how close each pool comes to the expected block solves for a perfect pool with zero hardware, software, and network failures. Then we can have a degree of confidence about expected performance in practice.

Wasnt that the whole point of this exercise anyway (and the original post for that matter?) 

And if not, why not? 

He only compared one pool to the perfect record. We only have his word that btcguild is significantly worse than the other pools in this comparison. He refuses to post the data. For all we know, btcguild could be middle of the road compared to other pools as is shown at http://www.l0ss.net/index30.php.

What do I,  as a miner,  care about your hardware, software, or network failures?  I want a return on my electricity costs + margin and the rest is your problem and why i pay you a fee/donation.  I dont care about normalized statistical calculations about the probability of x and y happening if the end result is the pool  solving less blocks than expected or hoppers stealing a share of my earnings.

Software, hardware, and network failures do not follow the binomial distribution of solving bitcoin blocks. Lumping them in as if they were recurring phenomena subject to a known distribution is just pseudo-math. The point is that you don't care to understand why, and that is fine. Feel free to hash where ever you like, for whatever reasons you like.

Judging from the growth we have seen at Mainframe,  im guessing we arent the only ones with this viewpoint.

Glad you guys managed to scare up some business.

[AnnihilaT]

Software, hardware, and network failures do not follow the binomial distribution of solving bitcoin blocks. Lumping them in as if they were recurring phenomena subject to a known distribution is just pseudo-math.

Without having precise details and reports on failure dates, times, and durations for each pool its impossible to do anything other than lump them in.   As long as this is done for ALL pools, its fair, isnt it?  The point im trying to make is that removing REAL occurences that affect availability and earnings only because they cant be predicted or determined to be recurring isnt really the right way to determine where to mine (or not to mine) either.   Your method suggests to completely abandon meaningful data simply because it may be phenomena (at least if if understand you correctly).  It could also be incompetence, you know (which does tend to be recurring and probably even with a known distribution)

[organofcorti]

organofcorti, I think I now know why we have disagreement here with you.

My math is done from point of view of a miner. Miner knows, that he wants to maximize his yield and therefore happy comparing all the pools with a hypothetical 100% efficient 100% honest and 100% competent pool. As such, number of blocks found and number of blocks expected is more than enough to make all the conclusion such a miner needs.

Your math seems to have a goal to make things needlessly complicated, incorporate into it as many irrelevant variables as possible, and basically to sink the truth in a sea of bullshit.

If you are not happy with my classification of your efforts, could you explain why you never ever calculated in this thread number of blocks that a pool is expected to find?

I think you should read my post again. I was showing deepceleron how it could be possible to look at variation in pool luck using shares per block.

I have never mentioned wanting to include 'irrelevant' variables.

I never mentioned that I was not happy with your efforts.

I also have never made any indication that number of blocks found in a time period is a good indicator of pool luck, when average shares per round seems a more easily calculated index. So, no, I won't do calculations based on blocks per unit time. I can calculate for you the number of difficulty 1 hashed expected to find a block, but I'm hoping I don't have to. 

Was this just to get your thread to the top of the forum? Shame on you!

[deepceleron]

I'll give your thread a bump, and summarize my points:

- Bitcoin block finding is random - pools may have runs of bad or good luck, but past results can't predict how a pool will perform in the future,

- To say a pool is cheating users based on luck is speculative, because even with many rounds of data, the statistics can't say that the probability is outside of expected variance. If I flip "tails" 10 times in a row in my coin-flip game, how do I then defend against allegations of impropriety just because it is unlikely? If my pool has 10 unlucky rounds in a row, should users be entitled to accuse me of stealing their earnings?

- Cheating by pool operators is hard to detect. Many mechanisms could be employed, such as only withholding very lucky block finds, diverting some user's shares to a second 'dark pool', adding non-existent shares to the pool to get paid for work not done, etc. Improving mining clients can help - it is possible for a miner to know that they submitted a winning share of higher difficulty than the bitcoin target, and the submission of a winning share can be locally logged; when the pool op knows that users know when a block was found, cheating is harder.

- When calculating "luck", even for curiosity's sake, one must convert the shares per round to a percentile or sigma of expected length, using good math aware of the true Bitcoin probability underlying pool shares, otherwise you will have skewed findings.

- Losses from pool hoppers is not hard to detect. Is the pool's hashrate graph jumping up at the start of every new round? In a proportional pool, your round earnings should be inversely proportional to round length. When you find that you are not making as much per submitted share as you should in short rounds, and are also able to submit fewer shares than you should have been able to in short rounds, it's time to jump ship.

[tysat]

If anyone here has some illusion about big pools like deepbit protecting them somehow from hoppers read this post written by a miner with 30 Ghps :

https://bitcoin.org.uk/forums/topic/137-mmc-celebration-thread/page__view__findpost__p__979

it's *really blatant* just how badly the hoppers rape long term miners on short rounds. I was losing about 50% of my BTC on rounds that lasted under 5 mins.

If you mine with a proportional pool the question is not whether you lose money or not, the question is how much money you loose. (it's much more than many  people think, btw)

Losing 50% of his BTC on short rounds at deepbit?  Sounds like someone doesn't know how to do math....  There would have to be a ridiculous number of hoppers for that to happen.  They may hurt some on shorter rounds, but at a giant pool like deepbit it should barely be felt.

That guy probably just had some bad luck with those short rounds where "he lost 50% from hoppers being in the pool".

[Grinder]

Maybe so, but do you know how many hop (or can potentially hop) from deepbit's PPS to deepbit's prop? If this is possible, would it affect significantly overall deepbit hashrate?

The PPS fee on Deepbit is way too high, that would just be stupid. Hopping is done to maximize profits, and you don't do that by using a pool with a 10% fee. The pools are envious of Deepbit's market share and lots of people thinks it's too close to 50%, so they will say anything to get miners to move to other pools.

[organofcorti]

Maybe so, but do you know how many hop (or can potentially hop) from deepbit's PPS to deepbit's prop? If this is possible, would it affect significantly overall deepbit hashrate?

I never mined with deepbit, so I do not know the facts. These are questions and guesses, not statements of fact.

I don't know and I have no idea how to find out, so take the following figures as untested approximations.

If you look at other proportional pools, the increase from auto-hopping is in the order of 150 - 300 Ghps (correct me if I'm wrong). We could expect a similar amount from deepbit, making the hashrate increase from hopping only ~ 6%. There is no way this will reduce payoffs for fulltimers on prop by 50%.

If there are some miners who only hop from deepbit PPS to deepbit prop and back very few would be using an auto-hopper to do it (since so many more options are available).

Finally if you look at a graph of deepbit's hashrate over time any significant increase in hashrate that coincided with a found block and the start of a new round would stick out like a sore thumb. You don't see anything like that on deepbit hashrate graphs.

From what I've seen irl and in sim, the loss of income due to hoppers increases when the hashrate of the hoppers increases compared to the hashrate of the pool, and is only significant when the hashrate is a large fraction of the overall pool hashrate. I could be wrong though - if you think I am please explain why.

[c_k]

There is a lot of stuff i don't understand in this thread, in Vlad's defence i might say that he kinda makes it a little bit easier for me to digest and this thread made me stop trusting blindly in pool ops.

what do you guys have to say about rfcpool, it's not in the list. thanks

rfcpool is most excellent for a 24/7 miner imo

PPLNS FTW!