There is none, as long as it confirms that's fine.

Fair point, although 256-bit client seeds is way overkill. Not only would a malicious server have to guess which way you're going to bet (hi or lo), it would have to do a comprehensive search of client seeds for each server-seed it wants to test and then see if there's any statistical deviation. This is already out of the realm of possibility for an 80 bit seed, let alone bigger.

Furthermore, the statistically deviation drops off rapidly with a large amount of client seeds. Even with 40 bit client seeds, I can't imagine it's possible for a malicious operator to brute force a server seed that even has a 0.1% uplift over a randomly selected server seed.

Plus the reality is that for real provably fair validation, you don't want to trust the client anyway so the client seed complexity is pretty meaningless anyway.

And you will not provide a short grace period for current ruby holders to sell at your earlier promised price floor?

I don't really understand how you could make a promise to hold a price floor (and literally even quote the dictionary definition of "always"). As you know, people made investing and arbitrage decisions based on your price-floor promise  and you're now pulling the rug from everyone. I'm struggling to come up with a more charitable interpretation then you're effectively scamming all ruby holders.

And if you are indeed solvent, than I think you would do yourselves a huge favor by demonstrating this (either publicly, or to a trusted person like dooglus) of proof of assets and quantifying your liabilities (which include promises made liked fixed investing returns and compensation promise made last year to investors ). If you are not solvent, you should be looking to return as much money as possible to your creditors. Or at the very least, issue a debt-based token like bitfinex did

Your method is absolutely provably fair, and certainly does have advantages (like I think it's the best way to build an API) -- but it's very suboptimal from a users point of view. Realistically it's hard to get users to do the provably fair verification once, let alone for every single bet. Also with the nonce system even if a user doesn't record their server-seed hash (which, let's face it: almost all the time) once a person has made more than half a dozen or so bets (with the same seed) it doesn't matter as it wouldn't be possible for a malicious site operator to find collisions anyway.

I think the only way to make the one-seed-per-bet system really useful for users would be to provide a (small and easily auditable) browser plugin. The browser plugin itself should randomize the client seed (when a bet is happening) and itself verify the result of the bet (issuing an alert when it doesn't verify). The browser plugin should never advertise itself, so the site has no way of knowing if the user is using it or not.

That said, I do think it's just far better to use a nonced-based system.

I'm not sure what this means

I think it's a bit too harsh to call it "fake" provably fair, as without a nonce it is still provably fair -- just perhaps suboptimal from a users point of view. But if you trust the client (e.g. you've audited a static version, or using some 3rd party client you trust) it's actually possibly better.


There have been a bunch of casinos though with "fake provably fair", the biggest offender I remember was the old 999dice which put a "betId" (instead of a nonce) in the preimage, which allowed them to 100% control the outcome. And then there's been dozens of sites with "fake" provably fair systems (pretty much 99% of all multiplayer gambling games that come out, they screw up the provably fair and it's not actually provably fair).


I would be trying to categorize sites (from best to worst):

* Trustless
* Provably fair  (follows best practices)
* Provably fair (warning: suboptimal, not practical for human verification)
* Not Provably Fair   (game design makes provably fair impractical)
* Not Provably Fair   (for no good reason)
* Fake Provably Fair  (claims to be provably fair, but isn't)

Bits are just a fraction of a bitcoin.  1,000,000 bits = 1 bitcoin

So the withdrawal fee of 242.52 bits is just 0.00024252 bitcoin  (or 24252 satoshis)

If you're interested in a dice site with a crazy-good withdrawal system, check out https://bustadice.com  At the current rate, an instant withdrawal is only 242.52 bits and if you're not in a rush, you just need to pay 47.94 bits for a queued one.

And on top of this, it has pretty great privacy properties. I'm actually using it right now as a personal online wallet as it's so much cheaper than anything else (including traditional wallets).

The real reason it's so cheap is pretty amazing coin selection combined with segwit, like for example the last withdrawal I made is this:
https://blockchain.info/tx/151766501e26172d131bcd1b01f12397a5364186e06a3461c34f01e502381d3f

which was me paying for a domain renewal.

I think (or hope) you do not understand the ramification of what you are saying. You made and reiterated on moneypot's commitment to purchase back the rubies at a certain price. To unilaterally renege on your obligation here completely undermines any current or future promise you will make. In a business that completely relies on trust, I cannot see this as anything other than the death knell for MoneyPot if you choose to go down this route.


While I understand you made this promise an "always" (and even condescendingly quoted the dictionary definition of "always") I think no one would fault you if you wanted to exit in a reasonable way. I would think it reasonable if you formally announce the end of the "price floor" and give people a 3 month grace period to sell you their rubies. To simplify it for everyone (including yourself) putting buy-walls on exchange(s?) would seem to be the most sensible approach.

--

P.S. @JackpotRacer can you please quote my message and say "so you don't delete it!!!". It is my hope that if you do that enough times you'll learn to use quote tags, and not just bold and italicize messages in a wall of unreadable text.

My intuition is that it's possible, just not really practical. I think the way could be to have clients bet with the game server via a trustless payment channel (this whole thing is a big giant ball of complexity, and greatly limited by bitcoins script system, but 50% bets are pretty conceptually easy to support). Then the game server also has 1 payment channels open with each investor. So effectively each investor is running their own seed server, and gets each bet.

The main issue is that there is a crazy amount of edge cases, some of them that really affect the user experience (e.g. if 1 of N investors don't reveal their seed, the bet will have to stall until some timeout period which is probably measured in hours or days).

But frankly, I'm not really sure it's worthwhile focusing too much on investors. I think the bustadice scheme is probably "good enough", and doesn't open a giant pandora's box of complexity.

What I think is an area that could benefit a lot more, is improving player guarantees. Provably fair is obviously good, but I don't think it's nearly good enough. =] If you weren't cheated, it's easy to check. But it still requires checking. And let's say you *were* cheated, you have absolutely no proof (non-repudiation). And furthermore there's no protections against an operator simply stealing your money.

When I get some more free time (i.e. after bustabit v2) I'd like to experiment with the idea of generating all user deposit address in a bidirectional payment channel. And you only release your funds 1 bet at a time (i.e. it would be impossible for the site to exit scam).

Yeah, it's an unfortunate limitation that I've documented:



But fortunately the guarantees are better for players, which it is totally provably fair even should the game server and seed server conspire.



We've spent a lot of time on this too. So far we've come up with two other ways. One is completely provably fair for both investors and gamblers, but relies on blockhashes which makes it not real time

And we also have another really cool idea of doing *totally trustless* dice for users (basically through a payment channel), but offers no additional guarantees to investors (But fantastic guarantees to players themselves). Instead of being able to detect when they're cheated (provably fair) it makes it impossible for them to be cheated in the first place.



Awesome, thanks very much!

Nice! Thanks for making this right =)

Thanks for putting it so well. It's just another example of a example of bitstarz trying to screw their players, instead of any legitimate business reason.



And it's also basic ethics to never accept bets you are not willing or able to fully honor.  Had Saligan8six lost, bitstarz would've had no problem taking his money.

It's funny how you're on every bitstarz thread defending ridiculously unethical behavior (but have no problems calling out other casinos). If there is a cap on the amount he's allowed to win, he simply should not be able to bet such that would exceed it. It is absolutely not fair to allow someone all the downside of their bet, but refuse to give the upside.

I'm really sorry this has happened to you. Unfortunately there's not really much anyone here can really do, bitstarz is really one of the shadiest casino's around and has seemingly made a calculated decision that ripping off players is more profitable than being legitimate. I'd however encourage you to leave a reference to your story on their trust page:

https://bitcointalk.org/index.php?action=trust;u=307265

Just so that it helps other people find a history of their actions.

And leave a review on askgamblers ( https://www.askgamblers.com/online-casinos/bitstarz-casino-review/ ). Askgamblers won't care, as they make money hand-over-fist promoting casinos which ever casino gives them the most kickback, but it's a good idea to make your story as visible as possible.

It's largely me but I've definitely had a lot of help; especially  on the front end (me and css hate each other). And on the backend Daniel helped with some things (and especially testing) as we're code-sharing for a bunch of things, like the state of the art coin selection  .

Bustadice isn't "v2" of bustabit. It's more like "bustabit themed dice" but a totally independent site (and operated by Daniel, not me -- although I do have an ownership stake).


The actual v2 of bustabit is getting pretty close. Early next week I will be asking people to help test and find bugs (although if you want to get a head start, try dev.bustabit.com). Currently I'm working on a data-importer and then just need to do a lot of testing

No, you just keep it in your own wallet (or cold storage, or what ever you want). Your "onsite" is the amount kept as as "collateral". And the second that it's possible for a max-profit win that would cause your onsite to be negative (and thus you have a debt to the site)  the site will instead margin call you  (simply set your "offsite" to 0, and give you some free credits to reestablish your position)

I think somewhere on your end (ISP, country, network?) someone is DNS blocking bustabit

There's a lot of ways of thinking of it, some people like the borrowed analogy -- but I don't. I prefer a slightly more mathematical approach:

Normally you risk a max of 0.75% of what you physically deposit into the bankroll (the "onsite"). So if you deposit 1 bitcoin in the "onsite" the max-profit increases by 0.0075, and you get a portion of the profits and loses based on that.  But you can tell the site "I have a bunch more money offsite, and I want to risk based on that". So say you have 10 BTC in your cold storage, but don't feel like depositing it due to counter-party risk -- you simply enter it as an "offsite".

Now you are risking a max of 0.75% * (onsite + offsite). If that number ever exceeds your "onsite" it means you could potentially become negative balance onsite if someone won max profit -- so the site will "margin call" you. Which simply means setting your offsite to 0, and giving you dilution fee credits to reestablish your position