Is it stuck at block 34001 again?

If so, that's a hard-fork problem.

If not, try adding these lines to your clam.conf file and restarting:

addnode=24.20.184.148
addnode=65.102.47.162
addnode=66.169.88.135
addnode=75.131.208.152
addnode=78.0.29.137
addnode=81.190.41.203
addnode=85.17.81.169
addnode=142.4.201.123
addnode=207.61.182.125
addnode=216.46.33.120
addnode=220.253.2.201

This was posted in the PRCDice chat:

Click the 'gift' icon in the lower right corner.

I found a slight bug in the site:



The "profit on win" box isn't always updated correctly.

I just bet 4194 satoshis at a 1.10x multiplier, and won 419 satoshis, as expected, but the "profit on win" box shows 1719 satoshis, which is wrong.

I can't find a way to reliably reproduce it, but sometimes when I type in the "win chance" box and then click in another box nothing updates.

It seems very unfair to use SatoshiDice's spamming of the blockchain as a measure of popularity.

Other dice sites don't spam the blockchain, preferring to work off-chain and paying for their own hosting rather than distributing the cost to everyone who runs a full Bitcoin node.

That doesn't make them less popular.

JD has had more bets and paid out much than SD, but because it hasn't spammed the blockchain you would claim it is "less popular"? That's pretty twisted logic.

Oh absolutely not - I think it's a joke thread.

This is one of the longest running Bitcoin casinos.

Very few have [Paid Out Bils] for so long.

If you have any more suggestions feel free to email blobsrs@gmail.com

216 of the most recent 232 blocks (all but 16) were freshly dug 4.60545574 CLAM outputs.

Only 1 of the 38 blocks before that were freshly dug.

If what I said was true, your conclusion is also true.

However...

I missed out a small detail, and your real chance of staking (per second) is 1 in:

2^20 / int(value_in_CLAMs * age_in_days)

ie. the weight of your output is rounded down to an integer number of CLAM-days.

That means that if you split your outputs up into 0.01 CLAM units, they have (effectively) zero chance of staking until they are 100 days old.  (I say "effectively" because if your output rolls a zero in the sha256 hash, it stakes. But that (effectively) never happens).

Note also that the 2^20 is for minimum difficulty. At the moment we're at around 10 times minimum difficulty, so you need to decrease your chance by a factor of 10 until the recently dug CLAM mother lode finishes its initial round of staking.

I've not seen an analysis of the best stake size given these two constraints.

Oh, and there's a 3rd constraint: no output is allowed to stake within 4 hours of its previous movement (staking or transacting).

No, I've noticed quite the opposite.

I used to get one or two per day, and recently I've seen none for 4 days.

I think it's just a question of luck. If you and I both try to stake a block at the same time, only one of us can succeed. Whichever of us has the better connection to the network "wins".

Note that it doesn't really matter - if an output stakes but that block isn't accepted, the output keeps its previous weight and so gets to stake again relatively quickly.

Only the lazy ones that don't sweep customer deposits into cold storage.

I notice that some addresses received multiple 4.6 CLAM deposits in the initial distribution.

See http://khashier.com:2750/address/xV4sJ8TkjZbkfAP4knLfRVgGVeNQTQQxPJ for example.

Was that a mistake, or what's going on with that?

The network difficulty is generally at or around the minimum.

That means that each of your 4.6 CLAM outputs has a 2^20 / (4.6 * age_in_days) chance of staking each second.

The distribution was around 72 days ago, and so:

>>> 2**20 / (72 * 4.6)
3166

each 4.6 CLAM output will typically take about an hour on average to stake.

When it stakes, its age is destroyed, so you won't expect to see it stake again for a while.

And the 0.1 you saw is pseudo-random, and can be as much as 1000 CLAMs if you're really lucky.

99% of the time it's 0.1 though.

They should all be in your wallet as soon as it finishes rescanning the blockchain. That takes a few minutes typically.

Oh, but maybe you didn't download the blockchain yet - if you're downloading it, you'll see them appear as it downloads. It looks like the 4.6 CLAM awards happened from block 558 to block 9262.

That's not how it works.

*Every* BTC address that had a non-dust balance on the date in question got 4.6 CLAM awarded to it.

Here:

24.238.75.8:31174
65.102.47.162:31174
75.131.208.152:31174
76.173.48.220:31174
84.194.247.232:31174
85.191.52.188:31174
93.103.131.59:31174
107.192.136.116:31174
142.4.201.123:31174
173.68.204.192:31174
184.9.244.44:31174
188.116.147.85:31174
203.20.114.252:31174
216.46.33.120:31174
220.253.2.201:31174

I didn't even get that far.

Any BTC, LTC, or DOGE private key which had some non-dust amount of coin on it some time in early May this year will have 4.6 or so CLAM on it too.

Simply export the private key from your BTC (or LTC, or DOGE) client and import it into the CLAM client.

Alternately, you can just copy your wallet.dat from the BTC data folder into the CLAM data folder, then run "clam-qt -rescan" to have it check all the private keys in that wallet.

A natural concern is that the CLAM wallet software will steal the BTC from the private keys you give it. I have given it private keys with hundreds of BTC on, and it hasn't stolen any of them.

If you're concerned, you can make sure the private keys you give it have already been emptied out of BTC - then you don't have to trust the CLAM software.

Even if you sort by amount paid out I still don't think SatoshiDICE would be "The World's Most Popular Bitcoin Game".

The only metric I can think of by which SatoshiDICE is the most popular is in terms of blockchain space used.

I thought about investing yesterday.

Would have been a great time to do it, but I was worried that Road2 would just keep winning and winning so didn't.

I always was a nervous investor, even on JD.

It doesn't matter if you switch or not if each roll is independent of all the others. He was just unlucky.