I would just like to thank SatoshiDice for making me realize I have a severe gambling problem, even though I had only visited casinos (local indian casinos, not Vegas) a few times in my life.  I would also like to thank them for the downpayment on a new house for my parents

This bit is not entirely true.  MOST pools run default bitcoind rules, which set aside a small portion of each block specifically for no-fee transactions with a high priority.  Only a few in the past have run custom rules which blocked free transactions.  I know Deepbit at one point ran special rules that required above-average fees (more than what the standard client would include) once blocks were above 50KB, but I believe they've changed that.

Just as an example, recently BTC Guild upgraded from the default rules, which set aside 27 KB in the block for high priority/no-fee (or high priority/low-fee) transactions.  The new rules running at BTC Guild set aside a full 100 KB for this purpose.

In less than 24 hours, there has been a noticeable improvement in low/no fee transaction confirmation times.  By just a few pools (although BTC Guild is ~30% of the network, so I guess that counts as a lot) running larger blocks, the backlog gets cleared out extremely fast.  It's not uncommon for a BTC Guild block to confirm 95-99% of transactions currently in its the memory pool.

I've updated the Worker Management page to change how the Minimum Difficulty is displayed.  It now shows the recommended hash rate for each difficulty, rather than just a number with no explanation.

Looks like it's doing the classic problem with sorting numbers.  10 is showing up after 1, but before 2, etc.  Will take a look to see what setting will fix that.

Deepbit still pushes out the occasional 200+ KB block.  All pools create small blocks at times.  The way bitcoind handles putting a block together means right after a previous block is found you will likely not be including a significant number of transactions, especially if the previous block was a large one that included most of the transactions your node had record of.

1) PPS Rate is displayed because it is a known constant (for ~2 weeks at a time).  PPLNS Rate is subject to variance, so displaying this would be misleading since the past <X> shifts have no influence on what the next <X> will be paid.  The PPLNS Stats page does show a last 100 shift value for people to see how good/bad luck has been in the recent term, but it is only provided as a measurement, whereas the PPS Rate at the top is designed to be informative of current rates.

2) This statistic would not have much use since both of them will always be decreasing due to network difficulty.

3a) I'm looking into adding greater depth on the charts, however it is very demanding given how large BTC Guild is to generate these charts.  Additionally, your individual miner is subject to hashing variance, which means the shorter the time frame, the less accurate the charts become.  I am trying to implement something for this though!
3b) There is no plan to implement a chart reset, since the data used to generate the charts is also used to generate your 24 hour earnings statistics on PPS.

4) BTC Guild does not keep track of the difficulty of share you submitted, outside of meeting the minimum difficulty assigned to your Stratum connection.  Adding this would require rewrites to the Stratum pool code, just to add a feature that serves no purpose other than providing a statistic with no value.

5) Switching back and forth between PPLNS and PPS is fine, just don't trick yourself into thinking you can earn more by doing so.  PPLNS is a non-hoppable system, which means there is no way to predictably increase your BTC by jumping on and off of it.  If you think you have done so, it is purely a coincidence, and could just as likely have ended up in the opposite direction.



Sorry if it seems very negative, it's just that most of the requests don't add any hard data.  I'm all for number porn, but unless the numbers have meaning, they would just take time away from the many other things being added.  I tried my best to explain WHY the requests wouldn't be implemented, or what my eventual plans are in the case of #3a.

I have updated the second post in the thread to include an official Pool Block policy and general rules related to how the pool treats user data and actions taken on accounts.

Another UI Update:

When something is added to the 'News' section, a small red notification will appear next to that icon on your navigation bar to indicate it has been updated, similar to what you would see on social networking sites like Facebook.

Ah, yes, NMC is actually set to a 0.10 minimum withdrawal, but the message was copied from the BTC payouts which are a 0.01 minimum.  Since NMC is virtually dead, I'll put the limit down to 0.01 now.

When a bet goes to SD, it normally has a fee (unless it's not required).  Same when the bet result comes back from SD.  Sure, that transaction fee cost is built into their profit model, so it "comes from the gambler".  Just like the fees that VISA charges the merchants filters its way into how they price their goods.

SatoshiDice pays its fair share of fees on both sides.  Stating otherwise is a lie.

And don't forget: Satoshi Dice has probably paid more in transaction fees than the entire network combined throughout history (not counting mistakes and/or testing transactions).

Dice payouts include fees, as do most of the bets that go there in the first place.

Pushed an update to all of BTC Guild's stratum nodes this morning.  The nodes are now running essentially double default values:

500kb max size.  50kb set aside for low-fee/high-priority.  50kb minimum size so other transactions will get in if there aren't that many waiting for confirmations.  Already seeing a reasonable reduction in unconfirmed transactions as more blocks get pushed out with 2x the defaults.

And just like that, we made our first big block at 480 KB: https://blockchain.info/block-index/355354/00000000000002afd19324105e429f5d3bd578ff710cf2802f9c59f622e37857

Virtually wiped out every unconfirmed transaction our pool servers had seen since the restarts.

All stratum pools received a brief restart to update their block mining settings.  A change has been made since last night:

Max Size = 500kb
Min Size = 50kb
Priority Size = 50kb

I certainly hope some attempt is being made to return this obvious mistake back to the person who made the transaction.

The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.

New EU server up and running, getting the heck out of Hetzner!  DNS was updated and so was the Pool Stats page.  I'll give it an hour and then do a quick restart on the old EU-Stratum in order to try to force users to the new server.

The new EU server is copying the new bitcoind settings (500,000 byte blocks, with up to 50,000 used for free transactions if there aren't that many paid transactions waiting).

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

The first new server running non-default block rules is now running under stratum.btcguild.com (stratum4.btcguild.com for direct non-round robin).

This server is currently running the following rule set:
Blockmaxsize=500000 (double current default)
Blockprioritysize=0 (No space is reserved specifically for non-fee transactions)
Blockminsize=100000 (will include freebies up to a block size of 100 KB, but transactions with a fee take priority)


Other servers will be updated similarly later.  These changes should see a marginal increase (long-term) for PPLNS users, since they will favor blocks that generate more in transaction fees whenever possible.

EU-Stratum down again, this server seems to have gremlins.  Moving DNS to the old server until I can get a new one up.