BetterBets.io |V2 NXT betting + Shapeshift.io|🎲 DICE★PLINKO★PVP Game CORE

[BetterBetsDev]

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?

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

[1715312254]

1715312254

[1715312254]

1715312254

[1715312254]

1715312254

[BetterBetsDev]

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.

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.

[BetterBetsDev]

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.

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.

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.

[BetterBets.io]

https://twitter.com/Betterbets_io/status/702989622629015552

[Miyslovenic]

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

[BetterBets.io]

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

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

[NLNico]

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.

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.

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://bitcointalk.org/index.php?topic=1065847.msg12015013#msg12015013 (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://bitcointalk.org/index.php?topic=687571.msg12122724#msg12122724 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

[BetterBetsDev]

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.

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.

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://bitcointalk.org/index.php?topic=1065847.msg12015013#msg12015013 (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://bitcointalk.org/index.php?topic=687571.msg12122724#msg12122724 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

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

[NLNico]

Okay, I noticed the following:

You will notice that the "salt" parameter is optional. The reason for this is that during a live roll generation, the salt is derived from a millisecond-accurate system clock time which is enough to randomize it as an input.

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.

[RHavar]

Okay, I noticed the following:

You will notice that the "salt" parameter is optional. The reason for this is that during a live roll generation, the salt is derived from a millisecond-accurate system clock time which is enough to randomize it as an input.

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

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  

[BetterBets.io]

Okay, I noticed the following:

You will notice that the "salt" parameter is optional. The reason for this is that during a live roll generation, the salt is derived from a millisecond-accurate system clock time which is enough to randomize it as an input.

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.

I have forwarded your post to Lobos, he had to sleep though and will connect with you to get this changed. Obviously, we have zero intention of giving coins to the Bitcoin/Altcoin population only to cheat them, but there is room for improvement and I agree.

Check your pm's from ~50 days ago I didn't hear back from you on this.

[Kakmakr]

If I may ask, why did you go for the Rubies angle? Do you think it makes the gambling easier or more complex? I never understand why sites go for a Alt coin alternative and not stay with purely Bitcoin? Sorry if I ask a misguided question, but I am intrigued by these moves.

Thanks for any feedback in advance. ^smile^

[BetterBetsDev]

Okay, I noticed the following:

You will notice that the "salt" parameter is optional. The reason for this is that during a live roll generation, the salt is derived from a millisecond-accurate system clock time which is enough to randomize it as an input.

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.

You know, you're right. An the truth is, I never looked at it from that point of view ... I guess I just don't have the cheater/scammer mindset :-)

I sent you a skype contact request, lets talk about some technical details and then get this fixed.

[BetterBets.io]

If I may ask, why did you go for the Rubies angle? Do you think it makes the gambling easier or more complex? I never understand why sites go for a Alt coin alternative and not stay with purely Bitcoin? Sorry if I ask a misguided question, but I am intrigued by these moves.

Thanks for any feedback in advance. ^smile^

Hello,


Good questions, I don't want to bore people with all the details but when I first started working on the concept of Rubies and "Bet-Mining" it was back in August of last year. I made a post many months ago hinting about it, the whole premise for this was that "No player walks away empty handed". I wanted to see if there was a way we could have people play on BetterBets and even if they lost their BTC during a betting session they would still have something to take home with them, thus Rubies was born from this.

It has evolved many times and been reworked to become a top ten altcoin so that those who were loyal to Rubies would be extremely happy when they earned them. This is literally only the beginning though, and this coin will be far greater than it's early distribution model in time. On March 1st we are launching the March Madness promotion to further strengthen the foundation for Rubies, and you will see much of the work that has been done behind the scenes to make it amazing for everyone.

-Bjorn

edit:March Madness is going to show everyone we do not want to have Rubies centralized on our site, we are just the birthplace and one current business accepting it's usage. Keep this in mind as we show you what is coming soon!

[BetterBets.io]

Rubies Rain message now working, thank you for playing at BetterBets.io

[yahoo62278]

This is just 1 more way for all of you to be involved with RBIES. Dont miss out

[Bitinity]

Do you have a plan to add rubies faucet on your site? I think it would be great to see rubies faucet, at least for some new players who have not own any rubies. Just in case it is possible, since you are using moneypot.

[gordonhill]

Do you have a plan to add rubies faucet on your site? I think it would be great to see rubies faucet, at least for some new players who have not own any rubies. Just in case it is possible, since you are using moneypot.

Hi Bitinity. Yes we have. It is a part of future versions to our site.
That said, and with the new model purpose by the MP team , which it will support alt-coins, them the adoption of rubies faucets will be a true reallity.


Keep playing at betterbets.io

Cheers!! ●‿●

[moneypot]

Do you have a plan to add rubies faucet on your site? I think it would be great to see rubies faucet, at least for some new players who have not own any rubies. Just in case it is possible, since you are using moneypot.

Hi Bitinity. Yes we have. It is a part of future versions to our site.
That said, and with the new model purpose by the MP team , which it will support alt-coins, them the adoption of rubies faucets will be a true reallity.


Keep playing at betterbets.io

Cheers!! ●‿●

Confirming this, we are working on Rubies (and other alts) integration, hopefully should be ready within the next month or two

[BetterBets.io]

A big thank you to Jayce for creating the new banners and our Sig!

Light Theme Banner


Dark Theme Banner