Lol, love it!  And, of course: https://yourlogicalfallacyis.com/the-gamblers-fallacy

Ideally you want the lowest difficulty that doesn't overload the servers or your bandwidth, which will vary on your hashrate. If you have one GPU, you don't want the diff so high that you aren't telling the pool that you are working very often.  If you have a GPU farm, there is no need to have a low diff that is constantly sending the pool shares.

As I discussed in more detail a dozen posts or so above, it doesn't matter over the long-term, but lower difficulty will give more reasonable day-to-day variance to slow hashers.

This can't happen. The solution that you are trying to solve includes the pool op's payout address.

If we are speaking of probability before the events occur, then it is correct to say that over the course of 6 rolls, on average 3 will be heads and 3 will be tails.

But yes, once you actually start making the flips, you cannot make any determinations of the next flip, based on the previous ones.

Same with mining. One can calculate beforehand, the average number of shares that they might submit for a given difficulty over a period of time, but the actual results will vary and have no bearing on previous results.  A higher difficulty is going to to have a higher  variance, and one can argue that a lower difficulty should be used to provide more "fair" (or even) payouts over the short term. But if you are mining for weeks/months, it should all even out. Some days you will be unlucky and get less than you "should", other days you will be lucky and get more than you "should".

The whole point of difficulty is to let the pool know how much you are working. Ideally you would submit every single *hash* that you produce to the pool. In that case the pool's hashrate would exactly match your hashrate, and you would be paid perfectly based on your percentage of work. But that's obviously completely impractical. With a higher difficulty, you submit shares less often, which will cause some variance between your hashrate, and the hashrate that the pool assumes you are producing. The tradeoff between difficulties is reasonable to debate, but it boils down to how long a period of time is required to even out the variance.

I personally believe that the current difficulty is too high for low hashers to receive a reasonable variance, but that's just my opinion.

Slot firmware absolutely does not "force" a win.  So long as the casino is using a firmware that has been certified to yield a minimum RTP, they are in compliance. The RTP is, as you said, theoretical over a long series of pulls.  I quote from your link: "Slot machines are typically programmed to pay out as winnings 82% to 98% of the money that is wagered by players. This is known as the "theoretical payout percentage" or RTP, "return to player." The minimum theoretical payout percentage varies among jurisdictions and is typically established by law or regulation. For example, the minimum payout in Nevada is 75%, in New Jersey, 83%, and in Mississippi 80%. The winning patterns on slot machines – the amounts they pay and the frequencies of those payouts – are carefully selected to yield a certain fraction of the money played to the "house" (the operator of the slot machine), while returning the rest to the players during play. Suppose that a certain slot machine costs $1 per spin and has a return to player (RTP) of 95%. It can be calculated that over a sufficiently long period, such as 1,000,000 spins, that the machine will return an average of $950,000 to its players, who have inserted $1,000,000 during that time"

That's all that happens. The machine uses a new RNG roll for each pull, looks that up against a payout matrix designed to give a certain percentage back over time, and the result of that roll is the result given to the player.  Nothing more, nothing less.

Hi H2O,

I agree with you that difficulty does not affect rejects, and it does not affect profit. The only thing that should affect rejects is how often blocks are changing, how quickly your server notifies us, and how quickly we submit shares to you.

The purpose of using a lower difficulty is to increase the accuracy that your server considers us to be working (ie, variance). As difficulty goes up, the variance between what your server considers our hashrate to be, and our actual hashrate, increases.

Over the long haul, pool difficulty is meaningless. I may get lucky and produce more 512+ difficulty shares than statistics would suggest (where my MH/s on your server would show higher than reality), or unlucky (where my MH/s on your server would show lower than reality). Over enough time, it should all even out.

As an extreme example, we could say that, over the long-haul, solo mining BTC (super high difficulty) is just as profitable as pool mining BTC (low difficulty). Probably even more profitable because there would be no pool fees. But pools exist to share the luck over many people, reducing individual variance.

So who is to say what a reasonable difficulty is that balances server load with the desire for low variance? Well obviously that's your call, and the ideal is vardiff to set low difficulty for smaller rigs and high difficulty for larger rigs. But your 512 difficulty is well out of the norm for smaller rigs.

Sidenote: I really do like your pool, I don't mean to be difficult (no pun intended). But you asked for a logical argument for lowering difficulty, so there you are

I've been on this pool for a few days and experienced no problems and received good payouts. I haven't decided whether to make this my permanent home or not because of two issues:

* As mentioned by many other posters, 512 difficulty is way too high to expect reasonable variance for small GPU mining, especially on low difficulty coins.

* No accountability. I am happy with my payouts and have no reason to suspect the operator is anything but honest, but am accustomed to being able to audit a pool more than I can here. Any pool operator can cheat the system regardless of the accountability they provide, and ultimately it boils down to whether the payouts seem accurate (which they do here best I can tell), but more details about which coins were mined, when/where they were exchanged will provide more piece of mind. This information doesn't need to be in real time if the pool operator wants to protect his algorithms (although it's trivial to determine which coin we are mining based on the difficulty).


I love what I've seen so far and hope you consider these suggestions.

I made a Google Spreadsheet that retrieves MtGox values (and several other API sources): https://bitcointalk.org/index.php?topic=249522.msg2649736

It's designed to keep track of wallet and pool btc and altcoin balances, but feel free to pull the mtgox code out for your purpose.

I have created a Google Spreadsheet to keep track of my various coin holdings.

There is a separate sheet for each coin to keep track of where the coins are located (wallets, exchanges, pools, etc.), and a summary page to total everything up. I'm sure many of you have already done something similar.

What may be useful to others is that the spreadsheet has the ability to update itself using:
  The current BTC<->USD exchange rate from MtGox
  The BTC<->AltCoin rates from CoinChoose.com
  BTC, LTC FTC, BQC, TRC, and YAC wallet balances from blockchain explorer sites
  mmcFE based pool balances (a large number of altcoin pools are mmcFE based)
  BTCGuild pool balancess

To Do:
  Use additional exchanges to supplement MtGox when getting BTC<->USD price
  Coin balances from exchanges
  BitMinter pool balances

The code to do all the updates is written in Google Script and is open to examination.

Instructions:

  Access the document at https://docs.google.com/spreadsheet/ccc?key=0AtMHbfi9Ki83dHZUaWJ6ZGZXVVZsUFpSX016OG43dHc&usp=sharing

  You will not be able to edit the document or run the scripts until you make your own copy of this spreadsheet. Use the 'File -> Make a Copy' menu to make your own copy (you must be logged into Google or this menu funtion will be disabled)

  After you have made a copy, the "Update Prices" menu system will appear to the right of the Google Help menu after a few seconds

  Do not make any changes to the first sheet. You cannot currently rearrange coins without also adjusting code in the script.

  For the subsequent sheets (one for each type of coin), you fill out the rows describing your holdings as follows:
    Location: You can put any description you want here, except if you are entering a coin address and you want the script to get its balance, in which case you enter the coin address here.

    Holding: This is the number of coins you own in this holding. You can manually enter it, or if supported, it will be automatically updated for you.

    Holding Type: This is where you describe the type of holding. You can enter anything here, but these phrases have special meaning:
      Public Address: Indicates that you have entered a coin address in the location column.  For supported coins, the script will retrieve your balance for you from the appropriate block chain explorer.
      mmcFE API: Indicates that the holding is on a pool that uses mmcFE. mmcFE is the front end that probably 90% of pools use. You will also need to enter the next two columns (Pool API URL and Pool API Key), discussed below
      BTCGuild API: Indicates that the holding is on btcguild.com. You will also need to enter the next two columns (Pool API URL and Pool API Key), discussed below
 
    Pool API URL: Only applies when your holding is on a supported pool (currently mmcFE based or BTCGuild). Enter the URL of the homepage of the pool (eg: http://wemineltc.com/, http://www.fcpool.com/), etc.

    Pool API Key: The API key provided by the pool to use their API. Normally available from the "My Account" -> "Account Details" page on the pool

  Here is an example of how you would enter your BitCoin public address for automatic balance updating:
    Choose a row on the BTC (BitCoin) sheet and fill out these columns:
      Location: Your bitcoin public address
      Holding: You can leave this blank, it will update itself with the balance
      Holding Type: Enter 'Public Address' (without the quotes)
      (Leave the rest of the fields blank)

  Here is an example of how you would enter your wemineltc.com pool for automatic balance updating:
    Choose a row on the LTC (LiteCoin) sheet and fill out these columns:
      Location: Put whatever you want here. Eg: LTC Pool
      Holding: You can leave this blank, it will update itself with the balance
      Holding Type: Enter 'mmcFE API' (without the quotes)
    Pool API URL: http://wemineltc.com/
    Pool API Key: Enter your API key found at the "My Account" -> "Account Details" page on wemineltc.com. It will be a long random sequence of hexadeimcal characters.

  Here is an example of how you would enter a BTC holding that is not currently automatically updated (for example, on an exchange)
    Choose a row on the BTC (BitCoin) sheet and fill out these columns:
      Location: Put whatever you want here
      Holding: Enter the number of coins that are held in this location
      (Leave the rest of the fields blank)

  To perform the update, choose the "Update Prices" menu (integrated into the Google Spreadsheet menu to the right of the Help Menu), and then click "Update Exchange Rates" or "Update Wallet and Pool Prices" as appropriate. I will probably provide another menu option later that both in one click.

  There are plenty of coins, pools, and exchanges currently missing. I can add these depending on demand.

If you find this useful, please consider donating (BTC: 1L86EDpwUSm5GiJPZvXeCSXA2ebbEbBGBh  LTC: LQpXs9mzESQKwsZ3fTv8T8YW7KqmrQ2ibR)

I'm confused on which fast pool I should be using, fast.minepool.net or fast.ub3rl33t.com. The previous discussion in this thread seems to recommend fast.ub3rl33t.com as the newer and recommended pool, but the stats page on fast.ub3rl33t.com/statsAuth advises us to move to fast.minepool.net 

Same