Maybe you could post some references regarding how those services are exactly involved for those looking at this from the outside. I don't see either one of those cheating (maybe oraclize), but claiming *fully decentralized* would be wrong in that case.
To be honest, I'm not very familiar with ethereum and its scripting. I just went through the contracts on etherscan.io and took educated guesses and googled for things. After spending a bit more time, I actually /think/ cloudflare might not be able to cheat, because the results appear to be signed from random.org (but I have trouble finding/checking the code which verifies the signature, does it even exist?). My reading of the logic is that the TLS signature from cloudflare is checked, not the random.org signature, which if so, would allow cloudflare to cheat. But I very well might be wrong, as I said I'm not that familiar with this sort of thing
I don't really mean to accuse them of anything, they're just some concerns i have by reading their code. It'd be nice if they address the issue instead of side stepping it calling it "fully decentralized" which it
obviously isn't. If you use a centralized service (oraclized), to call a centralized service (random.org) through a centralized service (cloudflare) done with a decentralized service (ethereum) it doesn't magically become fully decentralized.
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!
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.
Now, I have no idea why you are posting the same questions, over and over, in
EVERY forum. 
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.
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.pdfFor his credentials as an auditor you can google him or go to his security blog:
http://vessenes.comThat is on our website. Along with all other documentation.
As an addendum to the audit, in relation to Oraclize and Replay issue (which I am guessing you allude to):
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. Otherwise, perhaps you are suggesting the oracle might have requested random numbers until a matching one >shows up? In which case:
Random.org JSON responses have a consecutive ID, so if we dropped some to advange ourselves in the game, by checking all of the bets and their respective responses it would be evident: at the end of the day, there would be some JSON responses missing, i.e ID 1, 2,3.. 5,6 present but 4 missing.Further information on TLS notary:
With TLS notary (by the author of it in IRC), the third party has to keep the data to prevent the source from manipulating their data and making it seem as though your captured data is actually not authentic. In other words, a lying "I never said that!" from the webhost people.
It actually is secure because it is like when you browse to a HTTPS secure site, you are able to see provably that they are X company (if you inspect the certificates). TLS Notary is essentially able to record those bytes in such a way that you can play them back later so you can authenticate the bytes again! Very ingenious. (But the math of how it does this in the whitepaper goes above my head.
https://tlsnotary.org/TLSNotary.pdf)
the notary server used at the moment is the default tlsnotarygroup1 notary - which is an "AWS oracle", as described here. So there is nobody having access to the secret, as you can easily verify indipendently by following these instructions and giving a look at the actual code for the pagesigner-oracles.
There are some great videos explaining this further. Here is one:
https://www.youtube.com/watch?v=b4ukd4I8S9AI could go on forever about this. But, as I said before, it is an issue of centralization v decentralization.
vDice is fully decentralized in that there is no server architecture. There are 3rd party providers that do run some server architecture. But they are not part of vDice directly. They just give it what it needs. So, vDice is still serverless.
