In the case of my pool, the difficulty is configured and used for everyone.  So iff a share is good enough for difficulty 32 it gets accepted.  If someone were to setup dynamic difficulty or user selectable difficulty they would have to track which work they gave at what difficulty to avoid the problem you are describing.  That shouldn't be hard, since the pool needs to track which work it has issued anyways.

It is probably my terrible web page, that I call all the users suckers on the web page, that the hash rate is low and I don't offer merged mining.  All these things add up.  I imagine I'll get more traffic once the ASICs start hitting but I'd be surprised if other pools didn't have a way to increase their difficulty by then as well.

192710 - hhtt (http://hhtt.1209k.com/)

If you send me the bet transaction(s), I'd be happy to look into your issue.

Sorry for the delay.  I've been out of town and this transaction hit a new and interesting database problem on our end.  So I had to spend a little time to figure out what happened and fix it.

It is corrected now, the payment is confirmed.

I've thought about user selected difficulties, maybe with a lower pool fee the higher the difficulty which gives people incentive to reduce database work for the pool.  I think that makes a lot of sense but as I don't know pushpoold code base very well it will probably take me some time to work out.

As an aside, apparently long polling works just fine.  Just not via the proxy I was using with my miners so I thought it didn't work.

In this case, as only 0-65535 are allowed values you don't need to sample, just use each possible input number once and see if the output numbers are all exactly even.

That is cool, roulette was always my favorite game in casinos.  I liked not having to talk to the croupier about anything and being able to pick the odds and payout by choosing different positions on the board.

Also, I need 0-00.

Reading your FAQ, are you absolutely certain that this is evenly distributed?

# convert 0-65535 to 1-38
$number = int(1+(($number / 65535) * 38));

Since 65536 is not evenly divisible by 38, it is impossible for your distribution of ball landings to be even.

I recommend reading and understanding the implementation of a good random int function.  Example:
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Random.html#nextInt(int)

The math is kinda strange, but it is absolutely crucial for what you are doing.  Good luck!

Payouts are working and detail pages are up for users.

Not related to satoshidice, but I've launched a mining pool.  Currently rocking out at 1.6 GH/s.

https://bitcointalk.org/index.php?topic=95378.0

http://hhtt.1209k.com/

I'd like to announce the Horrible Horrendous Terrible Tremendous Mining Pool

http://hhtt.1209k.com/

The special feature here is higher difficulty work units to reduce network chatter.  It uses difficulty 32 work units (for now).  Getting ready for higher hash rate butterflies in October.

If you have a 1GH/s setup now and see the shares scrolling by at one every few seconds, imagine what it will be like with a 40GH/s BFL SC Single.

There is simply no need for all that traffic.  The time when difficulty one pool proof of works made sense is over.

I've also made the JSON output formatted to be human readable, added more data to it (including progressive rolls).

We also now have an API to get information on a recent transaction, documented at the end of  http://satoshidice.com/advanced.php

To make it easier to create applications that integrate with Satoshidice there is a long-poll API for getting information about a past or about to occur transaction. This way an application that just sent a bet can make this HTTP call to get information about it. The query will not return until the transaction is found or the timeout (currently 60 seconds) is up. The following forms show how to use the API.

New bets at less that 52000, 56000, 60000.

The lookup.php page now has a JSON button to get JSON output of the current query.

Is there a way to configure the difficulty of the work units issued to miners?

My understanding (please correct me if wrong) that pretty much all mining pools (exception of p2pool) use a difficulty of 1 for work units.  I'm concerned with the ASICs coming down the line that will be too many work units and create trouble for mining pools and miners.

With my two BFL singles I see a work unit every few seconds.  With an ASIC 40GH/s single I would expect to see many per second which seems to be unnecessary network chatter and unnecessary DB work for the pool.

I think those amounts that are close are actually wins on less than 64000.

For example this one is a small win, but with the transaction fee taken out it ends up as a loss:
http://satoshidice.com/full.php?tx=f1af22ddf109fd284f1384dba01cb8421fabb219fd05f48075133bc7dfe4b640

They are not any of ours.  My guess is they are created by someone for interacting with satoshidice.  The "BTC" seems a little silly.  I mean, it is a bitcoin address, that it is for bitcoins seems a little redundant.

I made a new page to make some of the progressive stuff clearer and to provide some fancy QC codes for making bets from mobile devices easier:

http://satoshidice.com/progressive-detail.php?v=1

I might do something for the simple bets as well where a user provides a bet, how much they want to wager (or how much they want to potentially win) and it makes a page showing the address, qr code and exact odds and payouts.  Nothing magical there, just doing some math for people and making it more clear for confused players.

No, sir, that was me funding the pot a bit which is why there is no listed transaction for it on the satoshidice web page.

The under 64000 with a 3% house edge made no sense for a player to ever play.  That is why the numbers for it were strange so I've removed it for now.

As for the progressives, I thought that it was too confusing to have the three.  Now there is one tuned to go to reasonably high pot fairly often.

It looks like those are all pending now.