Vladimir's essential self-defence guide for Bitcoin Miners

[organofcorti]

Simulations of pool block finding for different lengths of time gives a good idea of how 'lucky' pools might be in the real world. In the histograms below, the 'luck' index = log((number of shares to find x blocks by pool)/(x * difficulty)).

 

Slower pools will have much larger variability than faster ones, but even after 1000 blocks found some pools will look 'unluckier' than others.

[k9quaint]

dear k9quaint,

 Your argument about "selection bias" makes no sense. Yes my selected example shows, some EXTREMELY unlucky pool. I have specifically chosen the most "unlucky" pool to illustrate my point. However, you completely failing to treat this in context of my OP.

The odds of finding outcome in a dataset is different than that outcome occurring in a single monte carlo run. You need to calculate what the odds were of finding a pool with luck that bad, not what the odds were that a specific pool would experience that luck in the future. One is more likely than the other, and misrepresenting the data in this fashion doesn't do anyone any favors.

My post was not about some theoretizing about hell knows what. It was about choosing a pool to mine with or not to mine with. BTC guild was a perfect example of a pool to not touch with barge pole on "bad luck" criteria. No more no less.

If one were to go back to June 1st and then decide a pool to mine in, you would be absolutely correct. Going forward, what sort of prediction would you make about the performance of BTCguild? I went and asked the pool operator about events that had an outsized effect on performance that were unlikely to recur. There were 3 and they were very visible in the data set. (DDos July 4th-7th, DDoS Aug 12th, a bad pushpoold patch from June 29th - July 2nd). Also, you didn't treat the invalid blocks correctly in your data set, but that is another conversation.

Are you trying to tell us here that btcguild's historical performance is ok and miners should go now and mine with them. Do you yourself mine with btcguild?

The historical performance is definitely subpar. However, after dropping those 3 periods the picture changes quite a bit. I do mine with them currently, although I didn't point any significant hashing power at them until August, after the dust had settled from the DDoS and patch issue.

As for the reference with chart you gave me as your argument meaning "other pools are unlucky too" . That chart has at best 20 days of data and statistically is not so significant as my 3 month dataset and therefore is dismissed.

You are going to throw out 20 days worth of data that demonstrates a clear trend in 4 pools (including the one your are discussing now)? When I come back in 10 days with 30 days worth of data, will you dismiss that as well? You were not even curious as to why 4 pools were clearly below trend and the other 2 were flat?

I do not see what point you are trying to make in this thread. It looks like you are nitpicking trying to come up with some criticism , if so than you are miserably failing at it. Please tell us what is your point if you reply.

First point:: I believe you calculated the odds incorrectly regarding finding a set of bad luck in the search space of pools

Second point: I believe you treated the invalid blocks found incorrectly in your data set

Third point: I believe you represented past data that contained extreme and discontinuous events as historical norms. If you going looking for a problem in the past and show how the performance deviated from expected as a result of those problems, that is fine. You shouldn't represent that search as the result of a true Monte Carlo run to be expected in future performance.

Fourth point: I believe you are dismissing data that disagrees with you because it is not "as significant". Your response should have been: "Oh, that is interesting, I wonder why that is." I wonder why those pools are under-performing and I believe that someone who claims to be providing a defense course for pool-shopping should wonder as well.

You are very right about one thing, with hindsight we should have absolutely avoided BTCGuild on 7 out of the last 60 days. I am trying to keep this discussion collegial and courteous, I am not trying to pick gnat scat out of pepper to just to troll you 

[k9quaint]

First point:: I believe you calculated the odds incorrectly regarding finding a set of bad luck in the search space of pools

That is only based on your assumption that it is impossible to have almost 100% efficiency in a pool (on accepted share -> solved block stage). I disagree and and I have seen plenty of examples of solo mining and pools hitting almost exactly 100% efficiency on small and large datasets.

No. But I don't think I can ever convince you of the difference between finding history vs the odds of it repeating itself.

Second point: I believe you treated the invalid blocks found incorrectly in your data set

I disagree. I have been effectively calculating the yield and I do not care if a block got invalid, lost in space or whatever, there is not useful reward with invalid blocks but there are accepted shares, hence I have added the accepted shares to the next block and this is the correct way to do it from my point of view. If you disagree than you would be happy to mine for a hypothetical pool which marks every other block as invalid. Would you mine for such a pool?

If every block was being marked as invalid, would that be a sign of "bad luck" or of a software problem. If, after the pool operator applied a patch and blocks were now being found successfully, would you expect the future runs to revert to every block as invalid? Or would you treat that as a discontinuous function instead of a continuous one?

Third point: I believe you represented past data that contained extreme and discontinuous events as historical norms. If you going looking for a problem in the past and show how the performance deviated from expected as a result of those problems, that is fine. You shouldn't represent that search as the result of a true Monte Carlo run to be expected in future performance.

I have presented 3 month worth of data. I have not selected it out 10 years of pools history. I do not care whatever events were there, excuses do not change the yield.

They don't change the yield, but understanding the events that were causal is much more logical than just assuming you understand the distribution perfectly. Congratulations, you found a pool that were you to possess a time machine you would be able to warn people from the past not to use it.

Fourth point: I believe you are dismissing data that disagrees with you because it is not "as significant". Your response should have been: "Oh, that is interesting, I wonder why that is." I wonder why those pools are under-performing and I believe that someone who claims to be providing a defense course for pool-shopping should wonder as well.

I actually have started from that chart, and than I have calculated odds for 3 month performance of some pools on that chart. However, one pool have shown extremely high "bad luck" while others, even though, below average in last few weeks over longer period of time hit almost exactly 0 luck line.

The thing my math shows is that on 3 month dataset 200 Ghps pools hit almost exactly 0% luck line while an order of magnitude larger pool is in area of a fraction of percent probability of being a simply a victim of variance.
 
My response is not what you have expected. This is exactly because I do not wonder what it is, I  know what it is. I know that 2 weeks is not enough data to make any conclusions with 99% certainty, particularly for 200'ish Ghps pools. On longer time frame however the picture is much more clear.

Well, I suppose I should just let you cherry pick your results and pass them off as statistics.

You are very right about one thing, with hindsight we should have absolutely avoided BTCGuild on 7 out of the last 60 days.

Glad we  agree on this one. My point though is that if you are 99% certain that a particular pool operator has managed to be either not as competent as he should have been or not as honest, than why would anyone want to bet on the next 3 month period with the same guy when there are alternatives such as PPS pools or pools which to not exhibit huge "bad luck" streaks.

Those who want to experiment with this they are more than welcome but it is not something I would advise.

BTW how ddos or downtime or whatever excuses accepting a share and not delivering statistically expected blocks is beyond my understanding. Thought, there surely could be a number of technical issues which can cause problems. In any case it is better to be with pools that are not affected by those mysterious factors.

Once again:  excuses do not change the yield and I do not see anything wrong with my suggestion to avoid pools which had extremely bad yield in the past.

You don't understand how a DDoS from a botnet could affect performance? Or a patch that prevented submitted shares from being aggregated correctly might skew results? I think I see now why your view on this subject is so narrow.

[Sukrim]

I think what he meant is:

You do calculate the probability of finding a valid hash but comparing it with finding a valid block (which is lower by design because of the probability of chainsplits/orphans being > 0).

[k9quaint]

I think what he meant is:

You do calculate the probability of finding a valid hash but comparing it with finding a valid block (which is lower by design because of the probability of chainsplits/orphans being > 0).

Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault, get the heck better connected and do not run it on some overloaded VPS, this might help.

If anyone think that I should have ignored invalid blocks and shares that went into them instead of adding invalid blocks shares to the next blocks, than I am ready to start a new pool which will declare 99% of all blocks invalid and this pool will have a perfect good luck on the rest 1% of accepted shares. I'll even throw in some guaranteed good luck into it, lol. Anyone wants to mine in such a pool?

In the end of the day there are 3 variables involved, the difficulty, number of accepted shares and number of solved blocks. That's it. There is no variable for "how lame is the excuse" and such.

So, if I DDoS the smaller pools that can't afford to buy as much bandwidth in perpetuity as I can afford to rent from botnets for a week and they experience degraded performance as a result. This is either bad luck or the pool operators fault according to you. I don't agree with that assessment. Does it degrade performance and harm miners? Absolutely. Is it predictable according to expected performance by a bitcoin pool? Not in my opinion.

Did I ever said that I am calculating odds of future performance? How is presenting 3 month worth of data out of 3 month worth of data is cherry picking?

Do not answer that, the questions are rhetorical. End of conversation with you, k9quaint.

You don't want me to answer the first question because it would be in the form of your quotes:
As an example, of a simple check any miner could to do in order to be confident in his pool
I do not see anything wrong with my suggestion to avoid pools which had extremely bad yield in the past.
And of course, this all started with your essay on "Is your pool cheating you."

You don't want me to answer the second question because it would also be in the form of your quotes:
I have specifically chosen the most "unlucky" pool to illustrate my point.
I have calculated odds for 3 month performance of some pools on that chart..

"Chosen the most unlucky pool" from what dataset? The dataset (http://www.l0ss.net/index30.php) I posted shows a strong negative bias over the last 20 days against the theoretical 0 luck line. Does the set of data that you examined (and then presented us only the small cherry flavored segment) correspond exactly to the theoretical 0 luck?

And what do you have against BTCguild anyway? You seem inordinately hostile and intransigent on this subject, declaring repeatedly that "excuses" do not change the yield". Well, nobody here is offering excuses. I am offering explanations. Bitcoin probability does not account for faulty software patch probabilities. You presenting the aftereffects of one as "some mysterious force" or "excuses" or "incompetence" makes it seem like you have a vendetta against this pool you have chosen.

You can't even calculate the odds of finding an "unlucky pool" when you go looking for one. Why should any of us believe you can find one that is cheating you?

[Syke]

Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault

No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks.

Your spreadsheet is slightly inaccurate because you are including invalids in the 'actual' column, but not in the 'expected' column. Until you can compensate correctly for the 'expected' number of invalids, it's best to leave them out of the 'actual' column calculations.

[organofcorti]

Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault

No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks.

Your spreadsheet is slightly inaccurate because you are including invalids in the 'actual' column, but not in the 'expected' column. Until you can compensate correctly for the 'expected' number of invalids, it's best to leave them out of the 'actual' column calculations.

Is there any non-falsifiable proof that a given block *was* actually invalid?

[AnnihilaT]

Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault

No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks.

Not entirely accurate.  WIthout going into details,  there are things which can be done to minimize and practically eliminate a block your pool has found from being orphaned (strictly speaking about BTC here and not other shitcoin chains).   In very simple terms its just making sure that you arrange very good connectivity between your pool and as many other nodes on the net as possible (especially the other largest nodes and especially geographically well spaced out).  

To see some effects of doing this, have a look at this post:
https://bitcoin.org.uk/forums/topic/117-mmc-one-of-the-fastest-bitcoin-mining-pool-in-the-world-with-a-proof/

You can see that in many cases Mainframe is the first to announce a new block to the network even when we didnt even find it.   Of course this can depend on the location from which these measurements are taken but i think it illustrates my point that measures can be taken and gives evidence that those measures can be effective.

[AnnihilaT]

Yep that is, "you treat invalid blocks incorrectly" stance. I got it. But how am I supposed to handle it? From my point of view, if a pool got invalid block it is pool operator's fault

No pool can eliminate invalid blocks. Invalids are expected and are a direct consequence of the 10-minute target and network propogation effects because solved blocks do not propogate instantly to every node on the network. Another blockchain with a lower target speed, say 3-minutes, would expect to have more invalid blocks.

Your spreadsheet is slightly inaccurate because you are including invalids in the 'actual' column, but not in the 'expected' column. Until you can compensate correctly for the 'expected' number of invalids, it's best to leave them out of the 'actual' column calculations.

Is there any non-falsifiable proof that a given block *was* actually invalid?

Yes.  Although it could take some research, i should think that it should be able to be verified by collating data from other pools and blockexplorer if a pool has falsely marked a block invalid/orphaned. 

[Syke]

Not entirely accurate.  WIthout going into details,  there are things which can be done to minimize and practically eliminate a block your pool has found from being orphaned (strictly speaking about BTC here and not other shitcoin chains).

Yes, what I said was entirely accurate, and I'll re-word it in case I wasn't clear enough. You cannot eliminate invalids. You can, at best, reduce them.

[AnnihilaT]

Not entirely accurate.  WIthout going into details,  there are things which can be done to minimize and practically eliminate a block your pool has found from being orphaned (strictly speaking about BTC here and not other shitcoin chains).

Yes, what I said was entirely accurate, and I'll re-word it in case I wasn't clear enough. You cannot eliminate invalids. You can, at best, reduce them.

fair enough. 

[wknight]

Thanks for the article. I enjoyed it!

[hawks5999]

God, Vladimir. You throw libel accusations around far too often. Please go learn a new legal term. You have completely worn out this one through cavalier misuse.

[hawks5999]

Again, your math is incorrect, even after trying to "correct" yourself.

Now that I know you are running your own pool and trying to grow it's membership it becomes clear that you are only interested in getting people to leave BTCguild and Deepbit and hoping to pick up some more subscribers in the process. Here I was just thinking you didn't understand and all I had to do was explain your misrepresentation of that data. It turns out, it is just fraud(don't want to be accused of being libelous... again). C'est la vie.

It is difficult to get a man to understand something, when his salary depends upon his not understanding it!
-Upton Sinclair

This quote can be used over and over in the BitCoin community, it seems.

[Brunic]

k9quaint, FFS, there are no fee PPS pools, this is your perfect benchmark if you want a baseline. Show your math or shut up. Instead of hard facts here is only endless innuendo, unintelligent accusation and finally libel is coming out of you. Way to discredit yourself. Ohh.. looky 40 posts many of which is just trolling me, nice job.

It turns out, it is just fraud.

It turns out that you a committing libel right here and right now. Cease and desist immediately. I demand retraction of libellous statements and an apology.

Don't worry Vladimir. Some of the silent guys around here already read your article, found it interesting and well-thought, and have followed your advices. I've quitted BTCGuild, and I found a new pool I'm really satisfied with.

It's normal to have criticism when you do something interesting (like your articles), it's part of the game. Just don't blow a fuse over them

[Sukrim]

Since there is no known way to consistently find blocks faster than the difficulty level and there are many ways to lower the over all return (DDoS, bugs, fees, latency, etc) there is a persistent negative bias on the distribution of pool performance.

Let's see:

DDoS:
Might make accepting shares difficult/impossible, maybe even sending out valid blocks to the network --> more invalids, but surely not more shares/block

Bugs:
They could lead to accepting + paying solutions twice, acepting + paying invalid solutions etc --> Might increase the shares per block

Fees:
Are an arbitrary concept, do not influence the shares per block, only the payment per share

Latency:
Maybe from miner <--> pool? Increases the stale share rate and might even cause some valid solutions not being pushed to the net (if pushpoold is not "brave" enough to dare to cause a chain split) --> might lead to more invalid blocks or even more shares/block

The real question is: How high is this persistent negative bias (that HAS to exist, with solo mining on a very well connected node as a baseline) throughout all pools and which pool is best there? Also: Why do some pools have a bigger negative bias consistently?

Oh and by the way:
Long Polls are also far too often VERY ineffective or too late, if you look at statistics by pool hoppers! These are the main cause for stale shares and can lead to significantly lower payouts, if you have a pool that performs porly there.

[Brunic]

I am just keeping the flame afloat so that the thread is on the top all the time. Trolls are only helping me out.  

Hahahahahaha! 

Never thought about that. Sir, you have my utmost respect! 

[hawks5999]

I say it as it is. Anyone accusing anyone publicly in writing of committing a criminal offence without supporting it with proof on "beyond reasonable doubt" standard is committing exactly libel, by definition (with some exceptions but even that there must be a reasonable cause and presumption  of innocence must be used until crime is proven). Go an and read some law books if you do not believe me.

If I only had mailing address of  k9quaint some legal paperwork would be put in motion right now.

So the Jr. Member of the forums, k9quaint, is supposed to be viewed as such an expert on the matters of the article and comments of the Hero Member, yourself, that we the unwashed masses would mistake his statement that you are a fraud as a statement of fact instead of a mere opinion?

Further we are to suppose that k9quaint's opinion is in fact an intentional false communication, and that it harms your reputation(assumes you have a good reputation, no?)? decreases the respect, regard, or confidence in which you are held(assumes you are held in any regard, respect or confidence, no?)? or induces disparaging, hostile, or disagreeable opinions or feelings against you(more than you induce yourself?)?

This is now twice that I've observed you reference libel as a defense in a debate. Here is the other: https://bitcointalk.org/index.php?topic=38668.msg474351#msg474351. Calls of libel are the last defense (or perhaps in your case, the first defense) of the coward. The only thing that appears to be factual in this whole exchange is the level of your pusillanimity and the weakness of your argument.

Oh and you are welcome for the bump.

[k9quaint]

Since there is no known way to consistently find blocks faster than the difficulty level and there are many ways to lower the over all return (DDoS, bugs, fees, latency, etc) there is a persistent negative bias on the distribution of pool performance.

Let's see:

DDoS:
Might make accepting shares difficult/impossible, maybe even sending out valid blocks to the network --> more invalids, but surely not more shares/block

Bugs:
They could lead to accepting + paying solutions twice, acepting + paying invalid solutions etc --> Might increase the shares per block

Fees:
Are an arbitrary concept, do not influence the shares per block, only the payment per share

Latency:
Maybe from miner <--> pool? Increases the stale share rate and might even cause some valid solutions not being pushed to the net (if pushpoold is not "brave" enough to dare to cause a chain split) --> might lead to more invalid blocks or even more shares/block

The real question is: How high is this persistent negative bias (that HAS to exist, with solo mining on a very well connected node as a baseline) throughout all pools and which pool is best there? Also: Why do some pools have a bigger negative bias consistently?

Oh and by the way:
Long Polls are also far too often VERY ineffective or too late, if you look at statistics by pool hoppers! These are the main cause for stale shares and can lead to significantly lower payouts, if you have a pool that performs porly there.

Vlad the Petulant had cited overall return as the gold standard for pools. I was pointing out that overall returns are likely never to be perfectly efficient for pools given all the things that can go wrong and the lack of known incidents/methods/etc that increase positive luck. That was why I was interested in the distribution of all the other pools Vladdie searched through. The data at http://www.l0ss.net/index30.php shows this bias for the previous 20 days and as more data is gathered, it should give us an idea of the size of the bias.

As for Vladdums claims to not understand how system failures could lead to invalid blocks, Mainframe Mining Cooperative cited the following:
"...with some unfortunate side effects of reduced I/O to one of the storage array disk clusters the pool cluster is using which was causing some latency and load issues for the pool. At the very moment we found block 142,496 we were getting this array back up to speed and im convinced that everything running a bit slower is what caused us to lose our first race."
https://bitcoin.org.uk/forums/topic/125-the-story-behind-our-little-orphan-block-142496/

@Vlad, now that you cry libel defense you can either come at me with a lawyer by filing a john doe lawsuit and compel bitcointalk.org to reveal my IP address and then subpoena my ISP for my identity and then proceed with the lawsuit to recover damages. Or you can add your claims of a libel defense to the list of things you have posted in this thread that are not correct. 

If Vlad ever bothers to post the data he supposedly gathered on the other pools we might get to the bottom of this. I doubt he will, since it will likely make his claims look baseless. Until that time, http://www.l0ss.net/index30.php speaks volumes with nothing to refute it.

[k9quaint]

Another one with illogical and incoherent arguments, taken out of content quotes and all the stupid dirty tricks. Not worth my time responding really.

Translation: Vlad will not post the data he claimed to have for reasons he does not want to get into.

I am waiting for the process server to notify me I am the defendant in a lawsuit.