As you might know already, dice2.win’s last official smart contract was our template into shaping our own nice2win’s smart contract. At its peak, dice2.win was processing over 3000 ETH of bets daily on the Ethereum blockchain.
The goal of this post is to archive the audit from 360.cn and the analysis offered by dice2.win at the time.
Hello everyone and welcome to dice2.win medium blog!
We decided to start our posts with an analysis of a recent review of our smart contract and infrastructure posted by 360.cn, which can be found here.
360.cn claims dice2.win is able to manipulate bets’ outcomes and believes there are multiple backdoors in the contract that allows us, the house, to tweak bet results in our favour and suggests a few ways we could exploit the contract being low on radars.
Before we begin, we would love to express our gratitude to Zhiniang Peng for such a detailed coverage of technicalities of our platform — this is in fact the most throughout analysis to date!
So, let’s dive in!
Selective abort exploit
What if house will “fail” my bets when it sees I am about to win big? Well, dice2.win is not special in this regard — any commit-reveal protocol (including our competitors, who base their solutions on client entropy and trusted third party oracles) with two transactions per bet is susceptible to this problem. Mitigating this in a fully decentralized setting is a surprisingly hard problem, so we settle on a compromise — given that blockchain is truly immutable, any attempt to cheat on our side remains recorded forever and will be discovered by someone at some point. No way to cover the tracks.
Let’s talk numbers: dice2.win have processed 279,000+ bets (and counting), and we have refunded just under 200 (around 0.72%). Moreover, with every refund we issue (whether it’s high network congestion, an issue on our servers or any other issue making it impossible to process the bet normally) we do pay the full win amount as per the original outcome, and that’s a rule set in stone with our operations. We are simply not interested in cheating a few players and making an extra Ether or two — and never will.
Don’t believe us? Well, you have Telegram group and Ethereum blockchain to validate our words. And yes, apart from Etheroll, FCK and other games, we never remove any posts from our Telegram group with the only exception being spam messages ;)
Uncle Merkle proofs exploits
A bit of an intro for those who are less technical-savvy: sometimes Ethereum network decides to reorganize recent blocks, which can lead to the transaction placing bet be mined again. Because it is mined for the second time, it ends up in a different block. And because dice2.win uses block hash (a unique identifier of the block) as a part of random numbers generation, the bet outcome might change on the fly. Doesn’t sound cool, huh? A second ago you seem to have won 10 Ethers and now, because something changed somewhere, you lost. We don’t like that either and that’s why we set up a rule: the first block the bet gets into is used for computing the random numbers. If the transaction is re-mined later, we make sure the bet settles with the original block (it’s called Uncle block as it sits “next” to main Ethereum chain). In order to let the contract know that was the case, we submit a piece of Ethereum blockchain to the contract that is almost impossible to forge and that proves that there was indeed an block with the original transaction. And that’s what Uncle block Merkle proofs are for.
360.cn claims that it is possible to produce “fake” Merkle proofs and that dice2.win can use that to selectively settle specific bets with the outcome profitable to the house. Here we could write a lot of technicalities on how difficult it is, analyze economical feasibility of that and so on, but … let’s make it easier for everyone: for every “fake” Merkle proof that one finds in our current contract we will happily pay 25 Ethers.
Same applies to selective draw using Merkle proofs: find us an example of such an instance (blockchain never forgets, right?) and ask for a bounty :)
Old contract drainage
That’s where we are a bit ashamed. A very first release of Uncle Merkle proof functionality was exploited by some black hat hacker — of course 360.cn mentions that. What it doesn’t mention for some reason is that we resumed operations the same day, we lost only a portion bankroll due to strict management policies in place, but, more importantly, zero of players’ funds were affected — it was us who lost money, not players.
A note on competition
While we are thankful to Zhiniang Peng for exposing the weaknesses of the contract, we feel it is a bit unfair that our state-of-art contract is criticized for very traceable, dirty and tricky exploit possibilities, but there’s no mention regarding Oraclize-driven casinos (where all random numbers are coming from a middle-man, who can reorder them the way he likes without any traces), no credits are given to our support responsiveness and the most loyal refund policy and no attention is given to tons of copy-cats deliberately leaving backdoors after stealing our technologies.
Well, we are fine with that, in fact. The only part of the story we care about is our players and we are grateful for all of you to making dice2.win happen. We dedicate ourselves to continuously evolve our tech, fix issues and make sure that one day everyone will agree that dice2.win is the best and most fair gambling platform out there.
Thank you for being with us, and, as usual, see you at the tables!
