I think what stakeminers is doing is even worse.

You give them 1 BTC, they buy 10k of zebracoin, turn them into 11k of zebracoin worth 0.8 BTC but tell you that your investment is now worth 1.1 BTC (because if 10k ZEB is worth 1 BTC then 11k must be worth 1.1 BTC, right? Prices go up and down but that shouldn't concern us).

When you come to withdraw they let you withdraw 1.1 BTC (minus fees, of course), apparently not realising that this leaves them insolvent (they had to sell someone else's coins in addition to your 11k ZEB to get the 1.1 BTC they sent you).

I'd love to be wrong about this, and for there to be a rational explanation for the mismatching numbers we see on the site.

I have already listed my reasons for not stealing from your customers:

  1) I'm not a thief
  2) It doesn't work if the site itself is already stealing from them
  3) The amounts involved are currently too small to bother with
  4) With the millisecond timestamp in place only the site can cheat, not the players
  5) I have no reason to prove anything to you

I think it's fair to assume that if 20% don't want to vote, they also don't want to upgrade their client. We need >50% to upgrade for any change to actually take place.

Of course as things currently stand we have a single staker with 75% of the stake weight, so this isn't an issue. The 75% staker can safely accept a change that has >50% support and know there won't be problems with excessive forking and orphaning.

Not entirely. The block reward is 25 BTC. If I'm a miner and find that a block I just mined makes me lose a 1000 BTC bet it would possibly be in my best interest to withhold that block and let someone else mine a different block.

This is the first I've heard of 90% support being needed.

Incidentally here's the support for each petition over the last 10,000 blocks:

$ clamd getsupport
{
  "threshold" : 0,
  "window" : 10000,
  "endblock" : 805025,
  "startblock" : 795026,
  "support" : {
    "0000cb61" : 195,
    "02fde4a4" : 499,
    "066b223d" : 69,
    "26dfbf81" : 38,
    "5afa074c" : 3807,
    "694c26a6" : 413,
    "7a69a853" : 1664,
    "c9328886" : 46,
    "deaddea1" : 23,
    "e2ef93da" : 44,
    "ea06c089" : 1713,
    "eff96b06" : 26,
    "ff839af9" : 2261
  }
}

"5afa074c" (stop digging) has the most support, at 38.07%

I guess the problem is that being +EV the site makes very little money for itself. Ryan takes 10% of the sponsorship money, which most weeks seems to be just 0.1 BTC from Just-Dice and 0.05 BTC from Ryan - so he makes a 0.04 BTC loss each week, before paying for hosting or advertising. Doesn't leave a whole lot of room for an advertising budget I guess!

I expect his hope was that word of a +EV lottery word spread virally - it's not often you find a +EV game run by a trusted community member after all. It's unfortunate that the game isn't more popular, but I guess most people don't recognise a good deal when they see it.

Me neither.

Any "real" lottery you see will have millions of players, and you have a tiny chance of winning a huge jackpot.

Nobody complains that their chance of winning is too small.

Who cares if there are a million players betting $1 each or one player betting $1 million? The result is the same: you have a 1 in a million chance of winning a million dollars...


tl;dr: The site needs updating to talk about the early-bird bonus and how it shrinks over time. Good point.

Steps 3 and 4 can run in a tight loop on your server in a tiny fraction of a second. Nobody will see it happening. It's not about my connection speed.


Everybody who is following this thread already understands what I am saying and sees that I am right. You have some kind of a blind spot and can't or won't see it. I don't need to steal from your customers to prove that what I am saying is right.


I have given more than enough information for any reasonably intelligent reader to see why your game isn't provably fair. There is no burden of proof upon me here.


I am very different than the house. I don't get to pick which txid to use, or which particular millisecond to claim the game ended during.


I can say it already, and have done. Many times. You don't understand, and I get that. I don't think you ever will. I think you should really find something else to do, or at least find somebody qualified to take care of the technical aspects of your site.


I don't think I can help you any more than I already have done. I'm sorry. Find your smartest techy friend. Sit down with them and have them go through both threads with you. Have them explain everything to you and make sure you understand it.

The only thing that matters when assessing solvency is whether your liabilities exceed your assets.

You write on your site that your liabilities are 126 BTC, and it appears that your assets are less than 40 BTC. That means that you are insolvent.

What am I missing? Some of your depositors deposited altcoins, and so you owe them altcoins? If so, why not list your liabilities as X BTC + Y NET or whatever?


Maybe that's true, but why does it matter? People are questioning your solvency. Whether it is harder to manage 12 wallets than to manage 1 doesn't seem relevant to this question.


It isn't, but again I don't think this is relevant. The most important question is whether stakeminers is solvent or not. It appears from the numbers you have published yourself that it is far from it. Is that the case?

  1. buy a ticket
  2. wait for the game to end
  3. check if you win if you use the current time in milliseconds as the client seed
  4. if you do, go ahead and win, else add 1 millisecond to the time and go back to step 3

Doing this you win every time. Sometimes you will use a timestamp that is 10 milliseconds later than the actual end time. That's 1/100th of a second. Nobody will notice.

For me there are three reasons:

1) I wouldn't be cheating you, I would be cheating your customers. You still get your 1% cut. It's rude of you to invite us to try to cheat your customers.

2) I can't be sure that you're not already cheating. If you are, my attempts at cheating won't work.

3) Nobody is playing at a level that makes it worth while.


Since you started hashing the time in milliseconds into the result, it is no longer possible for players to cheat. Now only you can cheat.


I can't while you are picking the client seed so unpredictably. But you still could.

Edit: Earlier you said we should stop talking about whether you can cheat or not. But talking about whether you can cheat is exactly the same as talking about whether the site is provably fair. When you say "this site is provably fair" you are saying "there is no way we can cheat you without you being able to notice". Changing the thread title to be "99% provably fair" is meaningless. Nothing is 99% provable - it is either provable or it isn't. Just like you can't be 99% pregnant.

It's possible to use the blockchain in a provably fair manner - see pevpot.com for an example. They use a future block hash as the input to a calculation that takes over an hour to come up with the winning ticket. So even if the miner is trying to cheat (perhaps by withholding a block if it makes him lose) he won't know whether his block makes him lose for an hour, by which time it will have been orphaned by some other miner.

I don't know what site OP is talking about. It is possible that it's a site like yours which claims to be provably fair but isn't. Maybe it even *is* your site - I don't know.

Just make it so the calculation takes longer than the game takes to run.


You don't have to spend any money other than the fee - you can just send the million USD to one of your own addresses. And again, the sums involved don't matter. "provably fair" means that you can't cheat. It doesn't mean "we can cheat but why would be bother because it's only 4 cents".


I don't think it's even very hard. If there are only 3 transactions per second, I could send 10 transactions in that second and have a 10 in 13 chance of winning. That tips the odds massively in my favour if I do it every time. Currently it's not worth it because nobody's playing for anything but dust. But I guess you're hoping that sooner or later people will play the more expensive games, at which point you want to be sure that it's not exploitable - or people will exploit it, if only to show you that they can.

Which game are you asking about?

If it says that your roll is randomized according to the hash of the most recently found block, or some such, then yes, timing matters.

I don't know of anywhere provably fair that does that though for real-time games.

Well, so long as the calculation takes longer than the game I think it's OK. Most games are what, 30 seconds or less?

Maybe your members don't care if the game isn't provably fair. That's fine too. Just don't advertise it as provably fair when it isn't.

You can't verify that rolls are provably fair just by playing.


Yes there is. Look:

I use a satellite connection. I have a ping time between 600 and 700ms to pretty much anywhere. That's pretty bad, but I like living in the middle of nowhere, so it's a compromise I'm happy to put up with. My laggy connection has helped several sites diagnose intermittent bugs in their code, because it tends to exacerbate race condition type errors.


You're misrepresenting things there. First off, I don't represent any group. I'm speaking for myself. So your characterisation of "you guys" isn't fair. It looks to me like lots of individuals can see the problems with your site and are pointing them out to you. There's no need to see it as an us-against-them situation. Just read what people are telling you, and try to think about whether they make sense of not. This isn't a war.

The reason I don't like your "provable fair" system is because it isn't provably fair. The house can play against the other players and guarantee to win every time. I'm not saying you do, but you could. And that is what stops it being provably fair.

Ryan's bustabit site is a completely different case. The players on bustabit aren't playing against each other. They are all playing against the house. So the fact that Ryan knows the crashpoint ahead of time doesn't help him much at all. The only problem I see with his system is that there is a per-round profit limit. He could theoretically play his own game to "use up" some of the maximum profit and cause other players to cash out early. But he can't make them lose like you can on your site.


Yes. You can broadcast transactions. Everybody can.


I don't know if you made that particular transaction. I'm not actually online at the moment and my local bitcoind tells me "Invalid or non-wallet transaction id" so I can't look at the details. But that's irrelevant. You could have made another transaction at the same time with a txid which made one of your tickets win, and you could have selected that transaction instead. I don't understand why you can't see that you could do this.


I don't have a clear idea of how the system should be. It's a tricky technical challenge to make a multiplayer game provably fair. Ryan's pevpot is the only place that I have seen even really attempt it (and maybe an old lottery run by Dabs, but I don't remember if he ever launched it or not).

Ryan's solution is to use a bitcoin block hash from after the game ends, and to use a key-stretching function with a lot of iterations to make it impossible for anyone to know who won until an hour or two after the block is found. That works for him because he only has one draw per week. It wouldn't work for you, because your games last less than a minute and people don't want to wait to see if they won or not.

You can't use the traditional "(server hash) -> (client seed) -> play -> (reveal server seed)" technique, because you have multiple players, some of whom could be the house in disguise.

You can't hash the house pick the randomness at the end (like picking a txid, a time in milliseconds, or anything else non-repeatable) because the house at that point has perfect knowledge and can pick the randomness to make their own player win.

But stealing from Ryan's idea, I think a reasonable scheme could be something like the following:

  1) use some kind of client seed from each player (player's name + client-side random number, maybe?)
  2) use "the last txid after 10 seconds", or any other server-generated randomness
  3) hash those two together, then use a stretching function which takes 5 minutes to run to decide the winner

That way, you can't calculate which randomness to use in step 2 to win, because it takes 5 minutes, and you only have 10 seconds * number of ticket purchases at most (so maybe we need to use a longer stretching function when there are more tickets bought).

The key is that step 3 takes longer to run than the time you have available to pick the server-side randomness.

Using the Just-Dice design to make people feel like they can trust the site is a big red flag. I left negative feedback accordingly.

That's a step in the right direction.


Yes, but so long as the names are fixed before the last element that affects the outcome is selected, that's OK.


We've been over this. You seem to be saying that because there are very few hashes per second your ability to cheat is somewhat limited, since you can only choose between a few different winners.

Do you see how even if there is limited possibility for cheating, that is still possibility for cheating, and so not provably fair?

And you still seem to be ignoring the fact that the house itself can broadcast a transaction itself that makes a house player win. The fact that there are very few transactions per second makes it easier to cheat, not harder.

Also, on an unrelated note, one of your recent changes broke something. It looks like the participant list isn't being cleared out between games:

In my opinion you should stop using my stuff.