No, it can't be the developers. The behavior I'm seeing is entirely on the JD staking wallet, which the developers don't have access to.

All we're seeing is variance in action. I have thousands of outputs staking. Each output expects to stake about once every 40 days. Of those thousands, some are bound to be unusually lucky.

As it happens, I now have 4 outputs that have staked 5 times each, not just one of them as before, but none that has staked 6 times yet:

  54f0aa
  55e31f
  debed8
  e58636

You can probably fix it by shutting down the wallet and restarting it.

But I've updated the bootstrap too, at the usual URL.

I received a signature for a message that said:
  'this is a betking cold storage address'

The address which was used to create the signature contains a little over 4500 BTC.

Dean tells me there's ~100 BTC in the hot wallet too.

So that's a proof of assets. For real proof of solvency we would also need to see a proof of liabilities (ie. investment amounts) to make sure that liabilities don't exceed assets. The danger is that there are 10 investors each having invested around 1000 BTC, so the total liabilities are over 10k. I'm not suggesting that this is the case, merely that it is possible if each investor doesn't have a way of making sure his coins are counted in the claimed total.

Can you give an example? If the hash was FFEEDDCCBBAA99, and the first 5 characters, FFEED comes out too high, then which 5 characters do you use next?

Is this sjess all over again?

Of course. Why do you think we pay them?


Maybe take a break from the forum until you come down.


It's OK if you are unable to respond to my post with anything other than personal attacks. I get it.

The bug was fixed in Bitcoin on Mar 10, 2014. There was no need to do a hard fork since the bug wouldn't have had any effect until approximately 256 years after the genesis block.

The problem is that C++ doesn't define what happens when you right-shift a 64 bit integer 64 or more places. What most compilers do when you ask them to right-shift 64 places is to right-shift 0 places, ie. do nothing.

I don't know of a good way to do it, no.

The problem is that since the site can immediately know whether the jackpot has been hit or not, why wouldn't it be able to also know immediately before it happens, and therefore make sure to win at least part of it?

The jackpot is effectively a multi-player lottery game, and the only real solution I've seen to such a game is pevpot.com's. That was a weekly lottery where the seed was the hash of a particular future Bitcoin block, and the derivation function (turning the seed into a winning ticket number) took about 20 minutes to run. The 20 minute delay was intended to make it unprofitable for any miner to attempt to rig the result by withholding a mined block which made them lose (since by the time they figure out their block makes them lose it has already been orphaned).

That method is no use for a dice sice where you get more than one bet per second. You'd have to run the CPU-intensive derivation function for every roll, creating huge load on the server.

Note that even using bustabit's method the site would still know when the jackpot was due to hit and so could arrange to win it.

Previous posters were asking how the jackpot is divided when it hits. I don't think they got a good answer.

Suppose two people are playing when the jackpot hits. One betting 0.01 BTC and the other betting 0.99 BTC. Do they get half the jackpot each? Is it split proportionally to the size of their bets? Or something else?

What if only one player is playing and their bet is tiny? Do they still get the whole jackpot amount?

Hey NLNico.

I just noticed the solvency stats are broken for Just-Dice on your site.

The address changed a while back. The coins are now stored in xJDCLAMZ3Y7L5XQBfW85dY8SoKWLgovNtZ (usually about 20k) and xJDCLAMZreM6ZzJJ28kh5uYnT7ToCPGywr (about 1.4 million). These links should show you the current balances.

Signatures proving ownership:

Mining is a competitive business. Only the most efficient miners will survive. If Bob is paying twice as much per kilowatt as the Chinese miner then how can he hope to remain in business? There are no "participation prizes" in the real world. Only the fittest survive.


The hashrate has gone up due to improvements in mining hardware. From CPU to GPU to FPGA to the various generations of ASICs, each faster and more efficient than the last. Difficulty tracks hashrate. Hashrate doesn't track difficulty. Your chicken and egg analogy doesn't apply, since if anything higher difficulty has an inverse effect on the hashrate as uncompetitive miners drop out when they stop being profitable.


I only bothered correcting the point because that guy made the same error many many times in this thread and elsewhere. He thinks that the difficulty goes up on its own and that miners have to keep up, when in fact it's the other way around. If it doesn't matter to you, why comment on it?


The miners work for us, the economic majority. We are not reliant on them. If they misbehave we can fire them by changing the proof of work algorithm.

I'm just catching up on this thread now, and had *exactly* the same thought as you did... "Hang on a minute, isn't this exactly the same explanation that dice.ninja gave for emptying their cold storage a few weeks before they stole everyone's money?"


I would be happy to.

PM me a list of addresses, and a signature for each of them saying "this is a betking cold storage address". I will verify each of the signatures, and post here saying what the total of the balances on the addresses is.


BAC had registered prcdice.com, when Dean's site was running at prcdice.eu. BAC had prcdice.com referring players to prcdice.eu so that he could earn affiliate payments for each player he referred. Dean refused to pay BAC the his affiliate earnings. I forget why, and whether they ended up agreeing on any kind of a settlement, but from BAC's recent message I guess they didn't... You could argue that domain-squatting prcdice.com hoping people will land there accidentally is a bit rude, but however you see it you can't deny that BAC was referring players to the correct domain.

It seems to be working again now, thanks.

You have to be able to tell him what the passphrase is like. Then he tries modifying it in various ways to try to guess the bit that you remembered (or typed) wrongly. I don't see why you wouldn't think this would work.


I don't think so. It would be easy to "DOS" Dave by sending him a bunch of big wallets with a really long impossible to guess passphrases on them, and lying about what you "remember" of the passphrase. It would be quite reasonable of him to ask for some kind of payment up front to deter such attacks against him, because otherwise he's wasting his computing resources (and hence his money) on a wild goose chase.

Sometimes people complain that they've been staking for a long time and not got any stakes yet.

Since I made the new Just-Dice staking wallet I've been watching to see how it performs, staking wise.

I found there's huge variance. I made around 13000 outputs of size 100 CLAMs, and set them to split into 25 CLAM outputs when they stake.

Some outputs have staked incredibly well. This one staked 5 times in 8 days, despite only being worth 26 to 30 CLAMs for most of that time:


Whereas none of the 146 inputs to 462d2e worth a total of 14600 CLAMs staked at all in 9 days. I sent them all back to the hot wallet to top it up after a few large withdrawals.

I like the idea of using powers of 2 as the change amounts. That way any amount can be created by using at most one of each size of change.

What do you mean, corrected?

Just-Dice never needed correcting, and your post hasn't yet been corrected. I still don't understand why you would include the most reputable Bitcoin gambling site in a big list of scam sites.

Why is Just-Dice on that list of ponzis, scams, hacks, and thefts? Just-Dice took care of the over 60,000 BTC entrusted to it and returned it all when it shut down.

What issue are you talking about? I don't think I understand you. What might actually happen next time?

Edit: sorry, I didn't notice you had quoted me. The problem is I'm not able to reproduce the problem easily. When staking is going slow I'm in a hurry to fix the problem, but then it's hard to reproduce it to debug it. I guess I need to do the work on a testnet or a disconnected rolled-back fork of the main chain.

There's a better challenge open, too: there's over $10 billion worth of Bitcoins secured by "easy-to-collide" private keys. Simply collide a few of the bigger ones and take the money!

The fact that this hasn't happened should be proof enough that OP's system (whatever it is; I can't understand what he is trying to say) doesn't work.

It's part of a series of similar diagrams. I don't know where to find them now, but they were made by etotheipi I think?