Decentralised Gambling Game vDice Announces Crowdsale

[TwitchySeal]

Some interesting notes from the October Audit mentioned in your ($49) press release.

It's no doubt that you have the right to make a comment but it looks like you're enjoying making caustic remarks about other people and finding some fault . If you don't like this project or doubt that you could make one yourself. Just my opinion.

I don't like it when people use deceptive tactics to try and convince innocent people to give them money.  I call them out because I think it's the right thing to do.  I know it's hard to believe, but I have no other motivation other than helping honest people not get scammed.

It looks like you are trying to make me out to be nothing more than a troll in attempt to validate OPs inevitable decision to ignore me and anyone else they choose. 

[vdice_io]

The game works and the code is well tested. Go review it yourself.

I have =)

There is no need to be aggressive and start making wild, unfounded accusations. Let’s keep it civil please!

Sure, I'm merely asking some questions which you aren't giving a straight answer to =)

We have some of the finest developers in Ethereum on our team.

This I have no doubt

Our coders and game are live, working and can be verified. We are obviously legitimate.

Now, I have no idea why you are posting the same questions, over and over, in EVERY forum.  

Because you have been ignoring my questions for days, which make me believe you are hiding something I would think "blockchain nerds" like yourselves, would be happy to discuss things on a technical level

Requesting to kindly keep this just one forum.
It's really annoying to have to go and paste the same answer over and over again.

Sure, I'd be happy to keep it here if you reply to me here.

The very reason why the authenticated JSON-RPC APIs of random.org are used, is because of the "requestsLeft" field which is returned by each API call response ( https://api.random.org/json-rpc/1/signing ). This field content is tied to the API credentials specified in the query and is there to indicate how many requests are left in a given day.

However, AFAICT your contract never actually checks the "requestsLeft" field or the ids. Am I wrong? You also provide no tooling to check if any are skipped. Furthermore, this does not provide protection against oraclize making 2 or more requests at the same time, and re-arranging them. I would assume a properly designed contract would have an explicit checks for the id that it expects, and only accept a result that matches the one it expects?

Furthermore, using a service like random.org seems backwards, because there is absolutely no guarantee they're giving you a fair result. Contrast this provably fair bitcoin gambling services, where a cryptographic proof exists that the number was fair.

If we check all the TLSNotary proofs published on the blockchain (which contain the whole API response!), an independent auditor can verify whether any subsequent number in the "requestsLeft" fields is missing - when that happens, the auditor has a good indicator that something wrong happened (either on the Oraclize side - which sent more requests than expected - or by any external party knowing that specific API key (vDice itself & random.org)).

Why do you verify the TLS, when api.random.org actually provides its *own* signature. Checking the api.random.org signature seems to be the correct thing to do, not the TLS one. By verifying the TLS signature instead of the api.random.org one, it just introduces more opportunities for a party to cheat (notably: cloudflare, which the requests are going though).

Of course this doesn't say much about the intent in itself (can just be some failure in the HTTP request, which had to be sent again), but in general it provides some level of security against replay attacks.

Well, then it's not really provably fair as a player/investor has no way to distinguish being cheated with "http request failure"

I could go on forever about this. But, as I said before, it is an issue of centralization v decentralization.

Again this is nonsense. You have 1 decentralized part (ethereum contract) and 3 centralized single-points-of-failure (orclize, cloudflare, random.org). Players have significant less protections than playing at a current bitcoin gambling site, with a better user experience. I fail to see a single*advantage that your site offers a player, other than affording you the possibility of getting rich with an ICO

Give me 24-36 hrs to get back in full.

It's getting crazy busy at the moment. But thee are good questions and we will answer asap.

Thanks.

[vdice_io]

Really the issue is what RHavar wrote it's not truly decentralized if using centralized sites. I wish I could offer a way to actually help solve this dilemma but it's above my pay grade. Good luck

Yes, indeed. And we'll be replying in full asap. So many questions at the moment.

We didn't expect interest in the project to explode like this.

Thanks for your patience everyone. Full answers to tech. questions coming shortly...

[bitjoin]

Decentralised Gambling Game vDice Announces Crowdsale

NewsBTC recently got the opportunity to interview Jason Colby, the lead developer of vDice, the world’s first fully decentralised gambling game. As we dwelled into the conversation, Colby introduced us with many aspects of their new platform...

Link

Great if its done right. Can he do a decentralized poker site next please that would be something.  Whats interesting is that USA players can play with no worries over gov.  

[vdice_io]

Some interesting notes from the October Audit mentioned in your ($49) press release.

It's no doubt that you have the right to make a comment but it looks like you're enjoying making caustic remarks about other people and finding some fault . If you don't like this project or doubt that you could make one yourself. Just my opinion.

Lol. He does this to everyone.

Judging by replies I suspecting he is not a developer / technologist though. 

[TwitchySeal]

Here is our formal response as to technology decentralisation, fairness, trust etc...

The game works and the code is well tested. You can review it. It's all public.
There is no need to be aggressive and start making wild, unfounded accusations. Let’s keep it civil please!

 
It's not provably fair or decentralized though.

We have some of the finest developers in Ethereum on our team.
Our coders and game are live, working and can be verified. We are obviously legitimate.

But your game isn't provably fair.

Now, I have no idea why you are posting the same questions, over and over, in EVERY forum.  Huh

Because you and all these excited "journalists " keep posting the same stuff that isn't true and I wouldn't want someone who doesn't know any better to believe you and then give you money.

Requesting to kindly keep this just one forum.
It's really annoying to have to go and paste the same answer over and over again.

Requesting kindly you quit taking out $49 press releases and and creating fake accounts to interview yourself and posting big images to bury criticism....

CryptoCoinsNews Article About vDice's Success and Upcoming ICO

Anyway, these concerns are addressed in our 3rd Party Audit by Peter Vessenes.
You can read that here: https://blog.vdice.io/wp-content/uploads/2016/10/vdice_game_code_audit_october_2016.pdf

Yeah I did.  Did you?

Did you read this part?



Or this?



I hope dooglus stumbles across this thread soon.

[RHavar]

So the tldr is:

The site has an extremely weak trust model, significantly weaker than existing bitcoin gambling sites:

* random.org  can undetectably cheat (by picking any number they want)
* cloudflare can cheat, but if they do random.org will be able to detect it (and it'll be CFs word against random.org)
* oraclize can cheat, but it's semi-detectable (there's no tooling offered to detect it, but it's checkable, and oraclize has plausible deniability)


It is centralized by every meaningful definition. It uses a decentralized contract, to communicate with a centralized oraclize server, which sends a message through a centralized CDN (cloudflare) to communicate with a centralized random number generator (api.random.org).


AFAICT this isn't even a serious project, some low-hanging fruit like checking api.random.org's signature is not checked (which would remove the possibility of cloudflare being able to cheat). They also are buying reddit upvotes for 0.006 BTC each, and a bunch of "press releases" to promote the ICO.

Good luck, I guess.

[vdice_io]

So the tldr is:

The site has an extremely weak trust model, significantly weaker than existing bitcoin gambling sites:

* random.org  can undetectably cheat (by picking any number they want)
* cloudflare can cheat, but if they do random.org will be able to detect it (and it'll be CFs word against random.org)
* oraclize can cheat, but it's semi-detectable (there's no tooling offered to detect it, but it's checkable, and oraclize has plausible deniability)


It is centralized by every meaningful definition. It uses a decentralized contract, to communicate with a centralized oraclize server, which sends a message through a centralized CDN (cloudflare) to communicate with a centralized random number generator (api.random.org).


AFAICT this isn't even a serious project, some low-hanging fruit like checking api.random.org's signature is not checked (which would remove the possibility of cloudflare being able to cheat). They also are buying reddit upvotes for 0.006 BTC each, and a bunch of "press releases" to promote the ICO.

Good luck, I guess.

Thanks for the well wishes.

This has been answered many times.

And you have asked questions as a result of those answers.
We will be responding to those in full soon.

This is the basis for good debate.

I understand also that you run a competitor service.
So everything makes a little more sense now.

I suppose everyone here knows you're a competitor.
So they will keep that in mind when reading your negative opinions.

Thanks.

[RHavar]

I understand also that you run a competitor service.
So everything makes a little more sense now.

I suppose everyone here knows you're a competitor.
So they will keep that in mind when reading your negative opinions.

Ha. Funny. This seems to be the go-to response of every single shady gambling site I criticise. But amusingly enough, less than an hour or so before you posted this someone was asking on my site:

22:49 TheBoyzzz: What other gambling sites are there?
22:49 Ryan: There's lots, I'd recommend checking out the bitcointalk gambling section
22:50 Ryan: and having a look, and seeing what people think of them etc
22:50 Ryan: The biggest by far is primedice.com
22:50 Ryan: the one with the highest max-profit is betking.io
22:50 TheBoyzzz: Thank you I will have to check them out
22:50 Ryan: but checkout bitcointalk, it's the best place to start

...and then later recommended him to checkout MoneyPot, as he was US based. I think you'll find I'm pretty much the least competitive person out there. I really don't give a crap. The only reason for my skepticism is that I care about the crypto gambling community, and don't want to see people get ripped off.


Anyway, the fact you have never directly refuted my assertions, seems to be a tacit acceptance of them. I'll take that  

[vdice_io]

Sure, you have your opinion. Everyone does.

There are a lot of people here with competitor product.

IMHO They should say that, before they use bad words, wrong information and lies.

I am not accusing of this. Your questions are good. We have answered.

Just in general I mean.

[TwitchySeal]

[vdice_io]

"Man how sad is that guy forging images. Those who can't do..."

Excuse the delay here.
Re an open source way for people to validate tls proof checks off chain ;
As for pgsg proofs verification, this can be done with the opensource offchain-network-monitor or via the pagesigner-console tool (but needs our "oracles.js" details to be integrated there). The plan is to release an already-integrated pagesigner-console tool to make it easier, but the offchain-network-monitor already does it (you can find it on app.oraclize.it too)
API call \"method\":\"generateSignedIntegers\”

[vdice_io]

Further, please note early design choices made in your original contract: since then they have been refined during different audit reiterations. Those choices still present a solid approach considering the existing ethereum alternatives we have today.

The requestsLeft field is not being checked because there are cases in which it could fail (which doesn't necessarly mean there was some bad player involved). It is correct to say the id is not being checked, while it could.. this needs the contract to be updated accordingly. The id could be a unique identifier for the query and would indeed avoid Oraclize to swap different requests.

the json-rpc random api provides a signature. This cannot be verified straight from the contract code (rsa verify is still not available in ethereum), but can be checked from the tlsnotary-proofs (which contain a full version of the api response). The reason why the tlsnotary proof is there, is to provide a security layer which is agnostic to the random number generator service (the datasource). Also, Oraclize is working to get the tlsnotary verification to work onchain, while the rsa verify feature ethereum integration is still uncertain.

[TwitchySeal]

Is this true:

Participants in the vdice smart contract bear a small amount of risk from the
‘house’ being a bad actor, and from a bad actor internal to Oraclize.

[vdice_io]

Is this true:

Participants in the vdice smart contract bear a small amount of risk from the
‘house’ being a bad actor, and from a bad actor internal to Oraclize.

Nice of you to cherry-pick. I note also you are not a developer.
So you are just taking things out of context to try and make us look bad.

Anyway, I think we already answered to all the major points. But again.

----
1- "Replay Risk"
the very reason why the authenticated JSON-RPC APIs of random.org are used, is because of the "requestsLeft" field which is returned by each API call response ( https://api.random.org/json-rpc/1/signing ). This field content is tied to the API credentials specified in the query and is there to indicate how many requests are left in a given day.
If we check all the TLSNotary proofs published on the blockchain (which contain the whole API response!), an independent auditor can verify whether any subsequent number in the "requestsLeft" fields is missing - when that happens, the auditor has a good indicator that something wrong happened (either on the Oraclize side - which sent more requests than expected - or by any external party knowing that specific API key (vDice itself & random.org)). Of course this doesn't say much about the intent in itself (can just be some failure in the HTTP request, which had to be sent again), but in general it provides some level of security against replay attacks.   
----
2- "setConfig"
Oraclize are updating on-chain contracts in the coming days to support this. It's here for forward-compatibility and enables arbitrary Oraclize flags to be enabled/disabled. The very reason why the vDice contract needs it is to enable the "zero-confirmation query precomputation" feature.
----

[TwitchySeal]

Is this true:

Participants in the vdice smart contract bear a small amount of risk from the
‘house’ being a bad actor, and from a bad actor internal to Oraclize.

Nice of you to cherry-pick. I note also you are not a developer.
So you are just taking things out of context to try and make us look bad.

Anyway, I think we already answered to all the major points. But again.

----
1- "Replay Risk"
the very reason why the authenticated JSON-RPC APIs of random.org are used, is because of the "requestsLeft" field which is returned by each API call response ( https://api.random.org/json-rpc/1/signing ). This field content is tied to the API credentials specified in the query and is there to indicate how many requests are left in a given day.
If we check all the TLSNotary proofs published on the blockchain (which contain the whole API response!), an independent auditor can verify whether any subsequent number in the "requestsLeft" fields is missing - when that happens, the auditor has a good indicator that something wrong happened (either on the Oraclize side - which sent more requests than expected - or by any external party knowing that specific API key (vDice itself & random.org)). Of course this doesn't say much about the intent in itself (can just be some failure in the HTTP request, which had to be sent again), but in general it provides some level of security against replay attacks.  
----
2- "setConfig"
Oraclize are updating on-chain contracts in the coming days to support this. It's here for forward-compatibility and enables arbitrary Oraclize flags to be enabled/disabled. The very reason why the vDice contract needs it is to enable the "zero-confirmation query precomputation" feature.
----

Since I'm not a developer, could you please tell me whether or not the player is exposed to any risk of the 'house' being a bad actor.

I've read your response, and I think you're just explaining why you're doing what you are.  Not changing it.

I don't mean to take anything out of context, I'm just trying to keep my question as direct and simple as possible.

[RHavar]

Since I'm not a developer, could you please tell me whether or not the player is exposed to any risk of the 'house' being a bad actor.

I've read your response, and I think you're just explaining why you're doing what you are.  Not changing it.

I don't mean to take anything out of context, I'm just trying to keep my question as direct and simple as possible.

I believe that my summary is quite accurate:

which is confirmed by vdice where he explains the reasoning behind the limitations, and says that some will hopefully be improved -- and some of the tooling will be improved as well.


The real "problem" right now in current provably fair gambling is that:
a) You need to trust an operator with your money (until you withdraw)
b) If they do cheat you, and you detect it, it'll be your word against theirs

So there's absolutely a lot of potential to improve the current status-quo. But unfortunately vdice is (currently) a step backwards, because it's not even provably fair at the moment.

And even though I strongly dislike ethereum, it's actually probably a good platform for making trustless gambling practical. (It's possible in bitcoin too, but the UX would be horrible because you'd need a very complex custom wallet)

[BoXXoB]

Since I'm not a developer, could you please tell me whether or not the player is exposed to any risk of the 'house' being a bad actor.

I've read your response, and I think you're just explaining why you're doing what you are.  Not changing it.

I don't mean to take anything out of context, I'm just trying to keep my question as direct and simple as possible.

I believe that my summary is quite accurate:

which is confirmed by vdice where he explains the reasoning behind the limitations, and says that some will hopefully be improved -- and some of the tooling will be improved as well.


The real "problem" right now in current provably fair gambling is that:
a) You need to trust an operator with your money (until you withdraw)
b) If they do cheat you, and you detect it, it'll be your word against theirs

So there's absolutely a lot of potential to improve the current status-quo. But unfortunately vdice is (currently) a step backwards, because it's not even provably fair at the moment.

And even though I strongly dislike ethereum, it's actually probably a good platform for making trustless gambling practical. (It's possible in bitcoin too, but the UX would be horrible because you'd need a very complex custom wallet)

I trust one of these great minds to make that happen (points at RHavar, dooglus,...)

No but seriously I'd love to see something like that to happen. Would pretty much turn out to be the best thing ever

[TwitchySeal]

Is this true:

Participants in the vdice smart contract bear a small amount of risk from the
‘house’ being a bad actor, and from a bad actor internal to Oraclize.

[joksim299]

Decentralized app which rely on centralized services, this way it is not safe for players nor investor.
You should postpone your ICO 'till you solve those issues which RHvar pointed out.