Topic: [ANN][ICO] SmartBillions World’s first multi-billion-dollar blockchain lottery. - page 35. (Read 49667 times)

twofreckles to answer your question:
Admin was able to withdraw the surplus funds over the contract liabilities such as win payouts and token redeem. We were able to withdraw the remaining funds because there weren't any liabilities on the contract when the withdraw happened.
To answer your question, the Admin management rules were a bit changed now what was described in the post above but it used to be:

In you case if the 150 000 ETH would be rised and 1500 ETH from the hacathon would stayed in the contract Admin would be able to withdraw in this case 0.25 % of that sum per week - 378,75 ETH but only if the amount is higher than the liabilities of the contract.

If less than 50 % of the ICO goal would be rised - less than 100 000 ETH Admin would be able to withdraw the whole surplus over the contract liabilities. If 50 000 ETH would be rised and 1500 prize would remain in the contract Admin would be able to withdraw 1500 ETH, but than nothing more if the total value would be less than all contract liabilities.
This was designed to allow Admin to withdraw the funds from the Hackathon prize for example when the ICO would fail than Admin could withdraw the funds.
During the Hackathon less than 50 % of the sum was raised - 0 to be exact, so Admin was able to withdraw all the surplus funds over the contract liabilities - there weren't any at the time.

The new rules will be described in details and will be published before the new Hackathon. The Hackathon goal was to guarantee Investors protection, we've lost our funds but the problem in the contract was found, that was the HAckathon goal. Now the contract was improved and we will start new hackathon.

Additional information from the SmartBillions team

The initial contract was designed to optimize user experience.
The contract enabled the withdraw of lottery prizes up to 1 months after the draw by keeping a history of 163840 block hashes (hashes[]), which is much longer than the default history of 256 hashes available via standard opcodes. At the same time the initial contract reduced the participation of the player in the costs of updating the database by requiring an update of a maximum of 10 hashes, which corresponds to one uin256 integer (5000 gas). If the lottery would run more bets than 1 bet / 10 blocks, the players would keep the database of hashes up to date without an active participation of the admin.
In case the frequency was smaller the admin was required to run the putHashes(with argument 25)  function at least once per hour.
The admin failed to do this during the hackaton and the frequency of bets was much smaller than in the expected production environment.
An additional problem was the initializations of the database of hashes, which was vulnerable to exploits during the first period of 30 day, because the marker of hash creation time (hash >> 240) was set to the current period and the getHash function failed to detect that the hash is not initialized properly.
This let to the exploit of setting a bet with ‘000000’ (or ‘000001’) and waiting for more than 256 blocks until the contract attempts to read the draw hash from the database instead of the short term memory stored in opcodes.

In the new contract we have decided to make the players responsible for the maintenance of the database of hashes. If the frequency of bets will stay above 1 bet / 10 block the costs of the lottery for the players will remain as it was. In case the frequency will drop, the players will be required to store more information about the history of draws in the database (up to 25*10 hashes, 25 uint256 integers). In case the frequency of bets falls below 1 bet / 250 hashes the player will be required to collect the lottery results within 256 blocks from the draw block. If the draw block hash was not stored in the database of hashes and the player did not collect results within 256 blocks after the draw, the bet will be lost (the previous contract returned the bet value).

This solution makes the user experience more problematic but protects the investors against negligence of the admin.

Other changes include the correction of the transaction order in the transferFrom function, a change in the initiation of the database of hashes and a modification of the hotStore function to allow anybody to deposit funds in the contract and remove these funds afterwards.

The new contract is deployed. The admin has been changed.
We will start putting funds to the contract again.

Withdrawals by the admin are possible in the coldStore function.

function coldStore(uint _amount) external onlyOwner
 {
        houseKeeping();
        require(_amount > 0 && this.balance >= (investBalance * 9 / 10) + walletBalance + _amount);
        if(investBalance >= investBalanceGot / 2){ // additional jackpot protection
            require((_amount <= this.balance / 400) && coldStoreLast + 4  60  24 * 7 <= block.number);
        }
        msg.sender.transfer(_amount);
        coldStoreLast = block.number;
}

This line:
require(_amount > 0 && this.balance >= (investBalance * 9 / 10) + walletBalance + _amount);

guaranties that the admin can never withdraw more funds than: the 90% of the funds invested during the ICO plus the funds in wallets waiting to be withdrawn (these includes unpaid prizes due to lack of funds in the contract; however these prizes must have been claimed with the won() function before, otherwise the prizes are not known to the contract).

There is also an additional important limit that the withdraw amount must be smaller than 0.25% of the jackpot and this fraction can not be withdrawn more often than every 7 days (4*60*24*7 blocks).

This additional limit is waived if 50% of investors decide to disinvest.

This additional limit means that if there is a large lottery win waiting but the winner did not collect the results yet, then the admin can run away with 0.25% of the current jackpot , leaving 99.75% of the jackpot still in the contract. Thus this risk has a negligible effect on the collected funds by the winner. The regular withdraw of 0.25% per week by the admin to promote the lottery is an expected behavior.

The new contract is already online:
https://etherscan.io/address/0x103c2c150a2dbcc277ee084c59881978060c8c22
it’s being updated and tested by the development team and before announcing the new Hackathon.

Rumipl would you be so kind and explain it on number cause honestly most people don't get it, and to be honest I don't fully understand the withdraw cash by admin policy. Beside the note that most of the cash is not withdrawable.

I mean lets say hackathon bounty won't be broken. And during and ICO period 150 000 ETH would be raised.

So in the smart contract will be 150 000 + 1500 ETH ? = 151 500 ETH. What is the actual amount of money which admin can withdraw from the smart contract then?

I just find it concerning that the money that is supposed to be set away for prizes is able to be removed by the anonymous devs at a whim.  It would have made more sense if the funds were automated and released back to them at the end of the hackathon.  What's to stop them from just running off with the jackpot once the actual lottery is running? I'm not making any accusations, I'm just saying it looks fishy to me personally.

Why saying that. The hackathon rules stated break the smart contract and withdraw the funds. Hackers managed to withdraw 400 ETH the rest of the funds were protected in time by the Admin.
After improving the contract the new hackathon will be announced with a 1500 ETH in the contract.

Wow it looks like they went back on their word and didn't let the hacker keep the bounty. If that's not a giant red flag I don't know what is.

Lol people, this was so obvious and clearly stated that if you manage to crack the smart contract you can tak as much as you can. They were lucky to have those 400 ETH, and it was extremely clear to me. I dont get this MOANING and WHINING here. I can't wait for this ICO to launch.

You are just wrong and you keep posting post with wrong information.It was said so many times that Admin had an access to the surplus funds over the contract liabilities.
The investors are protected as well as the winners. This is stated in the smart contract. In that case there weren't any investors as well as winners. As the winners were able to claim their winnings after 256 blockx - that was the issue and in the withdraw time nobody claimed another win.

In that case, no assurances will be tangible doough to regain the trust of potential investors.

Backdoor or not, there's a front door!! the devs can pull money out of the contract anytime they want! And they are anonymous people! nothing is stopping them!

I think it will still be on schedule. And I still believe this project will goes on, another improvement will come then no one can break again into it. Everyone learns from mistakes, security will goes wilder than before, so better to watch this project because this is were things goes interesting.

There is something wrong, no need for an admin to redeem funds if the smart contract is well done, it Can do it by itself by sending back 80% of the funds an adress invested.

The fact an admin Can withdraw funds from the smart contract ruins the whole purpose of the project

very interesting to look forward and continuation of this project. one question, is ICO will delay? or on schedule? 

Accepted, it was stated in the contract that admin will be able to make fund withdrawals for redemptions and payouts. But does that give any form of legitimacy to the withrawals by admin at the hack of the hackathon?

I will wait to see if someone can analyse the code to see if there is no backdoor

The contact is public and the withdraw rules cannot be changed. Second hackathon will be announced today. The investors safety is the most important factor in this project and we are very serious about that, we want the community to validate the contract. We will start the ICO only if the Hackathon will prove contracts safety.

But what's the guarantee you won't be able to withdraw funds from the real contract ?

It was stated very clear in the smart contract that admin will be able to withdraw the surplus of the funds over the contract liabilities such as Token redeem and wins payout.
There're not tokens to redeem and wins to payout. Admin cant withdraw the funds if they are protected and guaranteed for the winners and Token Holders.

But what's worrying is that you were able to withdraw the funds, it should not have been possible especially After talking so much about the independant contract no one can tamper... What proves now that you won't be able to withdraw funds once you'll have funds from the ICO?

Aerys2 please find the official announcement. The SmartBillions contract is transparent and the hackathon main goal is to prove to contract security and guarantee investors protection.