3@ 1BTC
Assuming that this bid is for the vdice.io ICO, I would suggest that the bid gets blocked. From what I gather, they are seeking a ~10M USD worth ICO, based on having a fully decentralized and trustless ethereum gambling game. From what I can gather reading the contract code, it is neither: trustless, decentralized or even provably fair. I have been asking for the last couple days on reddit and here to discuss my concerns, and the serious response I've been able to get is:
And all your other points are just wrong.
and
I don't understand. You're saying you trust centralized more than decentralized
We respectfully disagree. That's why we love blockchain.
That's why we made the world's 1st FULLY decentralized gambling platform.
There are technical arguments we both can make.
But I think people in Bitcoin forum understand why decentralization is important.
I do not wish to jump to conclusions and accuse them of being scammers. But if they are unwilling to engage in a reasonable discussion, while asking for so much money -- I do not think they should be allowed to advertise
Nobody asked for $10 million. This is a lie!
Otherwise, we have repeatedly answered your technology questions. That is, in every single thread you post them.
Here is the full reply.
The game works and the code is well tested. Go review it yourself.
There is no need to be aggressive and start making wild, unfounded accusations.
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. Huh
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.
