Topic: BetterBets.io |V2 NXT betting + Shapeshift.io|🎲 DICE★PLINKO★PVP Game CORE - page 57. (Read 315811 times)

On a side note, what's the high-level motivation for wanting to use a timestamp? The client adds their bit of randomness with the client-seed, and the server already picks the server-seed and server-secret, so why do they also need a timestamp?

Even though many people hate MP's provably fair system, I think it makes a lot of sense as it's designed to be machine-auditable, and it's the absolute simplest way to do that. But since it seems rubies is user-facing, I'd strongly suggest to just copy JD's scheme, it's definitely the most user-friendly and human auditable.

Also seems my BB account had 1200 rubies in it, which like a true gambler I promptly lost. It's funny, because I did the same thing with clams when they first launched. I should stick to running casinos  

Okay, I noticed the following:
So I had to have a look. Basically: you should never use time within a provably fair implementation. It automatically makes the provably fair implementation 100% not provably fair

The reason is simple: it's extremely easy for you, as site, to do this:
- If winning bet > add millisecond.
There is no way for the player to know if a millisecond has been added or not. Therefor it's extremely easy for you to cheat players and therefor the Rubies bet provably fair implementation is not provably fair. Of course I am not claiming you are doing this and I personally would trust you guys. But provably fair is all about not having to trust the site owners.


(The "bitcoin provably fair implementation" is basically just questionable. RHavar and I had a discussion about it before and he finds it very unlikely to be really exploitable by the site and I kinda agree with that. But the Rubies provably fair implementation is really just wrong.)


Sure, I will PM my skype name.

Thanks for your input. Can we discuss technical details on skype (or some other realtime chat tool) sometime?

I understand what you mean, but disagree. The thing is, obviously we use provably fair so we don't need to "trust" the site. You give us bet results, and with provably fair we can verify if that's correct. For the verification script, IMO it means we can verify the bets without having to trust you. By making it server-side, we still have to trust you.

In theory if you are rigging it (of course you are not but example) then you would easily return the server-side results as verified too. By making it client-side, this trust would be less. Of course in theory we still have to trust that your JS script is legit, but at least we can check that (if you have the knowledge.) Actually that's why an external script (even if it's a site-made JSFiddle!) is much better.


That being said. I still disagree with some fundamentals as discussed a long time ago: https://bitcointalksearch.org/topic/m.12015013 (basically: needs to generate the clientseed between every bet in the browser with cryptographically secure method.) I don't think you guys changed that yet (to for example RHavar's solution.) I also discussed it a bit at Rollin thread - they did change it after few days: https://bitcointalksearch.org/topic/--687571 IMO the provably fair implementation is barely provably fair at this moment. So TBH I think that verification script isn't a high priority compared to that.


Obviously I don't think you are doing anything malicious or whatever, but the provably fair method can have some improvements. I also realize you have been busy and I can see the amount of time the Rubies addition must have cost, so I am glad you guys keep improving. Still I think that provably fair implementation should be "fixed" too


Anyway, thanks for adding the FAQ text, I will have a closer look at the Rubies bet algorithm if I got a time

We recently updated chat, still working on some issues that popped up. Sorry for the issues they will be resolved for improved chatting experience.

Looks like chat box getting error, my chat appears 2 times and it seems not only me who get that many users who chat there appears 2 times too

I've added a description of the provably fair algorithm to our FAQ (item #7 under the "Rubies" tab) which also contains the actual source code used. Our source code is in PHP but it should be trivial to translate into NodeJS or any other reasonable programming language.

Let me know if you have questions, concerns or need any additional info.

Yeah, I'll add a description to our FAQ.

Actually, the reason it was done server-side is that it actually calls the live roll-generation code with the parameters supplied by the verification page. I opted for this method in order to make 100% that there are no divergences between actual betting and verification code.

So given the above, I'd prefer to actually keep it server-side. Do you see a problem with this as long as I supply the exact method used to calculate the bet outcome so you can verify that it's correct and (optionally) implement this verification on your site?

Please don't get me wrong. I have no problem doing this client side, but I think there's a certain charm (code-wise) when the verifier calls the actual code which is used during live-betting.

Yeah, as Bjorn said, the RainBot is working, just the message needs some fixing. This will be done tonight.

Notifications is in the code, however it is still being tweaked to get better. All people in chat (within 30 minutes who have been chatting )will receive the rain and the event trigger is going to seem random, but is actually triggered by a betting event. I can't give away the event that triggers it because we want people chatting just to be social, the rain is just a nice thing to reward players. I'm sure it will be discovered in time what triggers the rain though, however for now it has not been officially announced until its working as we would like (notifications etc.). The 3 Rubies payout per rain is working though as I myself have received 15 coins over the past 24 hours.

Nice to see there is a rainbot on chat, but I still do not understand how the rainbot works? But why the amount of rubies rained by the rainbot is undefined? And how players know that they got some rubies from the rainbot, is there any notifications?

Yeh, if I see the script, it should be understandable


Still a description with some information should probably be somewhere but script works for me.

I can switch it to client side, it's not a problem. Once I have that you can copy/adapt it if you wish to implement verification on your side.

Does that answer your question sufficiently (at least for now)?

RUBIES [RBIES] ≠ RUBYCOIN [RBY]

Please check our main thread for RBIES:  https://bitcointalksearch.org/topic/ann-rubies-rbies-gaming-and-casino-entertainment-currency-1364104


Keep playing at betterbets.io

Cheers!! ●‿●

What algorithm is used for the Rubies provably fair implementation?

I was checking the verify script, but apparently it's server-side verification (would be better client-side.)

Hi Everybody,

we just pushed out a new version with some important fixes and updates.

Most important of all, we now have a self-hosted bet-verification page for Rubies bets.

You can see all the changes which went into this update on the dev post (2nd post) of this thread.

Enjoy and bet responsibly.

The MP team was just working on Cloudflare for the API at that time, it's finished so all should be fine. Good fortune everyone.

 Working Now.